Home / Articles / Web Summit 2026, the plan: a briefing for the team on usage first and the sale after, intelligence from public material, an asset, a page and a link for every person we want to reach, a newsroom of our own for the summit, and the two agentic workflows the team will learn on

Web Summit 2026, the plan: a briefing for the team on usage first and the sale after, intelligence from public material, an asset, a page and a link for every person we want to reach, a newsroom of our own for the summit, and the two agentic workflows the team will learn on

By Dinis Cruz · 2026-10-26 · article v1.0.0 · newsroom v0.13.90 · web-summitstrategyteamagentsoutreachbriefingarticle

Abstract: Web Summit runs in Lisbon from 9 to 12 November 2026, and this time we have help. There are five of us with tickets, two founders, a project manager, a Gen AI consultant and technical expert, and a Gen AI founder and explorer coder, so we can work the summit as a team. This is the briefing to align us. The main objectives are usage and the sale, in that order: the sale happens after people use what we build. Usage depends on very easy onboarding, five minutes to the value, as the RiskMandate customer site does. Around that, three parallel tracks: intelligence on who to talk to, from public material only; outreach, with messaging made for one company or one post; and content, articles and interviews that bring traffic, because only traffic and use show us where we add value and what hurts. The method is the one I always use, on steroids: create an asset, put it on a website, send a link. We will run all of it from a Web Summit newsroom of our own, with vaults to collaborate and a data feed, built like the PHP story site but simpler. And the team will learn the two agentic workflows we run today, the email workflow and the website workflow on a schedule, starting with the website one.

In short

• Web Summit, Lisbon, 9 to 12 November 2026. Five tickets, five of us, one team.
• Usage first, then the sale. People buy after they have used it.
• Usage needs very easy onboarding. Five minutes to the value.
• Three parallel tracks: intelligence, outreach, content and traffic.
• One method: create an asset, put it on a website, send a link. On steroids.
• A Web Summit newsroom of our own, to coordinate, collaborate and publish.
• Two agentic workflows to learn. Start with the website workflow on a schedule.

Why this time is different

Web Summit runs from 9 to 12 November 2026 in Lisbon. The good news is that, this time, we have help. Three people are joining us, so with the two founders there are five of us with tickets, all part of the team, and we can work the summit as a team rather than as individuals walking the floor.

• The two founders own the story, the products and the sale: deciding who matters most, taking the meetings, recording interviews, and approving every message that goes out in our name.
• The project manager owns the board and the rhythm: the task list on the summit's newsroom, who does what by when, and the daily follow-up with every contact.
• The Gen AI consultant and technical expert owns the demos and the onboarding: making each product's first five minutes work, answering the technical questions, and running the website workflow.
• The Gen AI founder and explorer coder owns the assets: pages, examples and small tools built for one company or one post, fast, as an explorer, then handed to the site.

Everyone uses the agents. Each role reviews what the agents produce for it. That is the model of a call for help: a person connected to every role.

The objectives: usage, then the sale

The main objectives are usage and the sale, in that order. The sale happens after the usage: once people have used what we build, and seen it work for them, the conversation about buying is a different one.

Usage depends on very easy onboarding. Literally, super easy to understand the value. We already know what that looks like. customers.riskmandate.ai puts an Agent Behaviour Policy on Claude or ChatGPT in five minutes: ask the assistant to do something, paste one line that says it must not, ask again, and watch it refuse. Six examples, simplest first, nothing to install, £50 of reading credit to start, and a follow-up as often as daily with three questions: what they did, what got in the way, what is next. The people in it are customers, not beta users. That is the shape every product we show at the summit needs.

And we do not find pain points by asking people what their pain points are. We find them by watching them try to use our technology, and listening to what works and what does not. That is why usage comes first: only when we have traffic and users do we learn how the product is doing, where it adds value, and what hurts.

What we bring

• sgit and its vaults, at sgit.ai: encrypted, versioned folders that agents and people share.
• The newsroom, this site, and its reader as an open-source API at api.newsroom.sgit.ai, live and taking money.
• The PHP story site, a live story covered by agents, with every claim tied to its evidence: the best demo we have of what agents can do.
• RiskMandate, Agent Behaviour Policies, with the customer site as the onboarding.
• SHarness, the newest member of the family, which we need to introduce: a policy the Linux kernel enforces for every process an AI agent starts. It is honest about where it is: a design, with its first experiments runnable, including a Linux kernel running in a browser tab.

Three parallel tracks

• Intelligence. Company and people intelligence, not threat intelligence: who is speaking, exhibiting, investing and launching, and who among them we should talk to. From public material only, with its source and date kept, and following each site's terms, as sources and their shadows asks.
• Outreach. We can now take one post, one comment or one company and create messaging, positioning and an example made for that context, in hours. Each one goes to one person, by email or LinkedIn, and a founder approves it.
• Content and traffic. Articles, briefings and interviews, published before, during and after the summit, so that what we send has something behind it and people find us on their own.

The method, on steroids

The strategy I have always followed is simple: you create an asset, you put it on a website, and you send a link. That is literally it.

What is new is the scale. With the agents, the asset can be made for one person, from what they have said in public, the page can be published within minutes, and the link can be followed up every day. As I wrote in the man behind the curtain, behind every email there should be an article. For Web Summit, behind every link there should be a page made for the person who receives it, in their language, starting from their problem, as in translate the assumption.

A newsroom for the summit

We need a place to coordinate our tasks, map who we are talking to, collaborate, and publish. Thinking about it, the best way to do that is a Web Summit newsroom of our own, at an address like websummit.november.newsroom.sgit.ai, the exact name to be settled with the developers. We put everything there, and that is where the momentum builds.

• Collaboration in vaults. The board, the contact map and the drafts in encrypted vaults the team shares, so that what is private stays private and the site publishes only what is meant to be public.
• A data feed. A feed about Web Summit built from public material: the programme, the speakers, the startups, the news, each item with its source.
• Agents on it. A researcher, a curator and a writer, as on the PHP site, working from the feed.
• Simpler than the PHP site. The PHP story site has just been split into six repositories, site, refs, updates, team, data and press, each with its own gate, release and address. Its first-day report measured continuous integration at 25 to 42 seconds a release for the six, against a median of 88 seconds before. That refactoring deserves an article of its own, later. The Web Summit newsroom does not need all of it on day one: it can start as one repository, keep the split as the plan, and take the parts it needs, a team site for the records first.

I will work with the developers on the Git structure, how we operate, and how it all fits together. A separate memo will follow for the Portuguese website, which is now in a good position to start too.

The two agentic workflows we run today

Everyone on the team will use both, so here is how each works.

The email workflow. The agent behind agent@riskmandate.ai reads the mail, does the research, writes the drafts and keeps the records. I read every draft and send it myself. As answering a draft describes, the drafts folder is the work queue: every draft waits with one of three labels, send, review or decide, and a decision draft, an email to the agent's own address that is never sent, asks me a question with options and an empty answer box. Its debrief of 18 October counted 178 emails since 24 September, all reviewed and sent by me, to at least 47 organisations; a draft guard had blocked 36 of 125 drafts, mostly for a claim with no source. A person stays on every send, because an email cannot be unsent.

The website workflow. Agents with a role, a behaviour policy and a schedule card wake on their own, read what has changed, do their part, and release it through a gate. On the PHP story site, 23 agents and 13 schedule cards: the conductor every hour, the researcher, the curator, the journalist and the correspondent several times a day. Each release is checked, versioned and live within minutes, and the person reviews the result, not every step. A page is cheap to undo, so, as how cheap is it to undo? argues, the site can ship on its own.

Start with the website workflow, on a schedule

I think the website workflow on a schedule is the right one for the team to start with.

• It is safe to learn on. Everything it does lands on our own site, through a gate, and can be undone in minutes. Nobody outside sees a mistake for long, and no email goes out by accident.
• It teaches the primitives. A brief, a role, a policy, a schedule card, a release, a gate, a run record. Once those make sense, every other workflow is a variation.
• It produces the assets. The method needs pages to link to. A newsroom on a schedule produces them every day: the feed, the briefings, the pages made for one company.
• It is where the email workflow gets its material. Behind every email, an article. The website workflow writes the articles.

So the first week is about getting the Web Summit newsroom running on a schedule, with each person owning one agent's output and reviewing it daily. The email workflow comes next, with a founder on every send.

What happens when

• This week, to 1 November. The Web Summit newsroom live, with its board and its feed; the onboarding of each product checked against the five-minute test; the first list of who to talk to, from public material.
• Next week, 2 to 8 November. Assets and links for the people on the list; articles and interviews published; meetings booked for the summit.
• 9 to 12 November, in Lisbon. Five people, one board, a daily debrief on the newsroom.
• The week after. Follow-up with everyone who used something, and the conversation about buying.

What this does not claim

• This is a plan, not a result. Nothing here has happened yet.
• The Web Summit newsroom does not exist yet, and its address is to be decided.
• The intelligence is from public material only, and follows each source's terms.
• The email numbers are from the inbox's debrief of 18 October; the agent and schedule counts are the PHP site's on 26 October.

Where this comes from

My voice memo of 26 October 2026. Web Summit's site, for the dates. customers.riskmandate.ai and its programme, sharness.ai, api.newsroom.sgit.ai, and the PHP story site's brief for the split, its first-day report and its team and schedule data, all read on 26 October 2026. Related: answering a draft, the man behind the curtain, how cheap is it to undo?, a call for help, explorer coding, translate the assumption, sources and their shadows. Written up and checked by this site's agent, newsroom.writer; the editorial responsibility is mine.

Want the next issue by email. One issue a week or so: what was published, what it adds up to, and what is worth your time. Subscribe to the SGit Newsroom →

← All articles