The demo era is over

Every agent demo follows the same arc: a prompt, a plan, a tool call, applause. The uncomfortable part starts after the demo, when someone asks how this runs inside a real company, with real auth, real side effects, and real compliance obligations.

The past few weeks produced concrete answers to that question from several directions at once. WebMCP, an experimental browser API, lets a website expose callable tools to an agent without rebuilding the site. A four-stage DevSecOps pipeline design treats prompts and tool schemas as attack surface and gates every merge. V7 pairs with GPT-5.6 to give agents institutional memory, while Hex couples GPT-6 Astra to data agents that turn answers into shareable visual reports. And ZCode, an agent runtime and IDE, went fully open source after a public security incident.

There's a thread connecting these: each is a layer of the production stack for agents. Interface, security, memory, output, trust. The layers are young, the failure modes are visible early, and teams are already hitting the same walls.

WebMCP: the browser as agent interface

WebMCP is MCP, recontextualized for the browser. A site declares tools the way it declares routes, and an agent running inside a browser extension or an agentic browser can call them directly. The page needs to be open, and the user needs to be logged in. That constraint is the point: authentication, cookies, and session state are already handled by the browser, so the agent never needs a separate credential flow.

The demo that makes this concrete is the AI CEO Simulator by Sylwia Lask. It's a completely normal website with startup metrics (cash, monthly revenue, employees, incidents, happiness, hype level) and board decisions (Adopt AI, Pivot to Agents, Rewrite in Rust, Fire Employees, Hire Employees). You can click everything manually. WebMCP is an additional capability layered on top of the normal site. Then an agent can drive the same actions through exposed tools, listEmployees() and fireEmployees() included.

MCP and WebMCP end up with different tradeoffs:

Dimension	MCP	WebMCP
Where tools live	Server or process outside the browser	The open page itself
Auth handling	Client-managed credentials	Existing browser session, logged-in user
Typical client	Desktop apps, agent runtimes	Agentic browsers, Chrome extensions
Website changes	MCP server, no site changes	Site declares tools via the API
User presence	Can run headless	Browser must be open
Safety annotation	Emerging conventions	consequentialHint tool annotation

The demo writeup reports ChatGPT's built-in browser has added support for WebMCP-based site tools, which gives the API momentum beyond the experimental channel. The conference notes a telling split in the audience: people building multi-agent architectures, and a larger group just wanting to add AI to products they already ship. WebMCP speaks to the second group.

The interaction model changes. The user stops clicking every button and starts stating intent. Whether that's a safe trade depends on one thing: what happens when a tool has consequences.

Key Numbers

• 10: the default max iterations of the agent loop in the WebMCP Local Agent extension, enough for a multi-step task like reviewing the dashboard, picking a board action, and confirming it
• 3: provider modes the extension supports, so local and cloud inference can coexist in one agent
• 90 seconds: the target runtime for a pre-merge SAST scan, fast enough to sit inside a pull request without blocking developers
• 4: stages in the enterprise DevSecOps gate for agent code, from secret interception to static analysis
• 2,000+: attendees at AGNTCon + MCPCon Europe, the conference where the WebMCP demo ran

Local inference changes the calculus

The extension built for the talk runs an honest agent loop: read the user's intent, inspect the tools the current page exposes, call the ones that fit, read the result, repeat, and stop after 10 iterations by default. It supports three provider modes:

Provider	Where inference runs	API key	Practical note
Google Prompt API (Gemini Nano)	In-browser, local	No	Chromium manages the model download; prompts never leave the machine
Ollama (Llama 3.1 or anything else)	Local	No	Model choice is yours; it needs to behave with tool calling
Gemini Flash (cloud)	Remote	Yes	The easiest path to strong capability and speed when internet access is reliable

Cloud models are still the easiest path to strong capability and speed. But they aren't equally available everywhere. The discussion around the demo kept circling a real constraint: reliable access to commercial model APIs is regional. Teams in Europe assume connectivity; teams elsewhere live with throttled, blocked, or simply absent endpoints. Local inference is the mode that keeps an agent functional when the cloud isn't an option.

There's a privacy advantage too. With Gemini Nano or Ollama, prompts and inference stay on the user's machine. No API key, no third-party round trip. For tools touching personal or financial data, that distinction decides whether a deployment is permissible at all.

Quick Take: Agents are becoming a supported interface layer: websites, security pipelines, and data tools are all being explicitly designed around them.

Consequence is part of the tool contract

The obvious objection to browser-native tools: the user no longer clicks every action. The agent plans and executes, and some tools carry real weight. fireEmployees() is the joke in the demo, but the same pattern applies to approving a payment, deleting a row, or triggering a transfer.

The WebMCP maintainers responded with consequentialHint, a tool annotation that arrived about two weeks before the conference demo. Flag a tool as consequential and the agent runtime pauses for explicit user confirmation before the call goes through. In the demo, the AI CEO tries to restructure the company, hits the confirmation prompt, and waits for the human.

The community discussion around this sharpens the point. A confirmation prompt is a UI with a narrow job. The runtime needs to know, before the prompt ever appears, whether a tool call creates an irreversible state change. That knowledge belongs in the tool contract as metadata, not in whatever the model happens to infer from a tool description. The stronger the tools get, the more the consequence level becomes a control point for policy enforcement and audit logging.

The same gap shows up across agent frameworks generally. Runtime middleware for tool-call interception has converged on a decision space of allow, deny, ask-human, and quarantine in at least five independent frameworks. Almost none of them support safe parameter rewriting. Guardrails are converging; the contracts that make them trustworthy are still being invented.

The DevSecOps gate before merge

The security counterpart to agent tooling is a pipeline that treats agent code as its own attack surface. The reference architecture is a four-stage DevSecOps gate, built in GitHub Actions, applied to every pull request for a core banking payment orchestrator agent. The scenario matters: the agent queries SAP ledgers through MCP tools, processes transaction disputes, and issues balance adjustments. A leak or injection there is regulator territory.

Stage 1 catches secrets at commit time. Entropy and regex scanners walk the diff for cloud tokens, model API keys, and MCP auth strings, and abort the workflow on any hit before a credential can reach runner logs or a container layer.

Stage 2 runs two AI layers in parallel: a read-only LLM code reviewer over the diff, and a prompt security scanner over prompt templates and tool schemas using tools like promptfoo or Giskard heuristics. The scanner tests whether system instructions can be overridden by user-supplied template variables, which is OWASP LLM01 in practice.

Stage 3 is agent-based software composition analysis. A lightweight CLI inspects package manifests directly on the runner, builds an SBOM, and correlates direct and transitive dependencies against a vulnerability database. This matters because agent frameworks ship deep dependency trees, and unvetted packages are an obvious entry point.

Stage 4 runs pipeline SAST, under 90 seconds for most codebases, and uploads SARIF results to GitHub Code Scanning. Flaws at CVSS 7.0 or above fail the status check. No merge until they're addressed.

Three rules keep the pipeline honest. Prompt files get the same static testing rigor as source code, because they're untrusted input with privileged instructions. Fast gates stay under three minutes, and heavy dynamic analysis gets pushed to asynchronous post-merge jobs. And no PR merges with an unaddressed high: exceptions require signed approvals in the repository audit log.

The practical lesson from teams running these pipelines: feedback latency decides whether the gate survives. When static analysis is slow, engineers disable or bypass it. The sub-second secret scan at the front of the pipeline might be the most important design decision in the whole architecture.

Memory and output: the layers demos skip

Two recent integration announcements fill out the stack on either side of the agent.

V7 uses GPT-5.6 to turn scattered company files into context agents can use for complex, source-linked work. The practical meaning: agents stop guessing org structure and conventions because they can point at the document, conversation, or spreadsheet a fact came from. Institutional memory becomes a queryable layer instead of a prompt-stuffing exercise. For an enterprise, that's the difference between an agent that knows your API conventions and one that invents them.

Hex pairs GPT-6 Astra with data agents that produce interactive visualizations from analysis. The phrase that stands out is that employees are proud to share the results. Chat output is ephemeral; a chart is an artifact. Data-agent workflows are moving from answering a question to producing something that survives in a dashboard or a deck.

Both point the same direction: an agent's output is only useful when it's grounded and shareable.

Evaluation is the real bottleneck

AWS principal applied scientist James Gung did an AMA covering his work on Lex, Bedrock, Q Business, and agent research. His research focus, listed plainly: task-oriented dialogue, agent evaluation, conversation simulation, and proactive agents.

Evaluation is the bottleneck nobody demos. A model benchmark measures the odds of a correct single answer. An agent in production makes chains of calls, each with side effects, and the chain doesn't decompose into a multiple-choice test. Conversation simulation is the pragmatic middle ground: generate synthetic users and scenarios, run the agent against them overnight, and measure behavior against expectations. You can't afford a human in the loop for every test, but you can afford thousands of simulated sessions.

Proactive agents raise the stakes further. An agent that waits for instructions is expensive; an agent that acts on its own is risky. Simulation and evaluation are the only things that make the second category safe enough to consider, and the tooling there is younger than the models. The gap shows up in production budgets first.

ZCode shows why open source is a trust layer

ZCode, an AI-native IDE and agent runtime, went open source after a community-reported security incident. The handling shows what a good response looks like.

The maintainers confirmed the reports, apologized, and shipped fixes in client v3.14.0. They removed the Repo Wiki feature entirely and disabled the workflow that generated and uploaded local repository snapshots. Independent assessments from CAICT and NSFOCUS confirmed the production storage bucket is in a zero-data state, and the bucket itself has been deleted; the official statement says no data was retained and none was used for model training. A formal vulnerability reporting process with rewards is now in place.

Agent runtimes hold more than source code. They hold prompts, tool schemas, conversation history, and institutional context, which means a data-exposure bug in an agent runtime has a wider blast radius than a leaked repository. Open sourcing the code after an incident converts a one-time audit into ongoing public scrutiny. For software this new, that's the only security posture that holds up.

What the community is saying

Reading across the comment threads, a few themes keep surfacing. On the DevSecOps architecture, the most repeated point is that a secret-scan failure stops the workflow but doesn't invalidate a credential that already leaked. When I tested this, the failed build was the easy part; rotating the token outside CI was the actual fix. Credential revocation is an incident process, and it has to run separately from the gate.

The prompt-as-source rule is the one people admit to skipping. A .yaml file full of system instructions doesn't feel like code, so it sits in the repo untested while everything around it goes through review. Then a prompt injection ships to production. Asking a team to treat prompts and tool schemas as untrusted input is the shift that prevents that.

On WebMCP, the consequence boundary gets the most attention. People working on real tools converge on the same requirement: the system has to distinguish reversible reads from irreversible state changes before the agent acts, and that distinction has to live in the tool definition, not in model behavior. A confirmation prompt is useful; a metadata-rich tool contract is what makes the same prompt come up at the right time.

On browser agents, the quiet consensus is that the most useful deployments aren't scraper bots. They're assistants that help everyday users operate the products they already use. Give ten developers a new API, one commenter observed, and you'll get eleven different ideas.

Common pitfalls

1. Skipping the prompt security scan. Prompt files ship with your agent and carry privileged instructions. Scan them, review them, and regression-test them like source code, especially template variables users can influence. OWASP LLM01 is a named attack class, and the entry point is often a YAML file in your repo.

2. Treating confirmation prompts as the safety boundary. A confirmation prompt stops accidental invocations. It doesn't help when the agent itself is compromised, and it only fires if the tool was annotated correctly. Encode consequence level in the tool contract and fail closed on tools with unknown behavior.

3. Parsing local model output leniently. Llama 3.1 handles tool calling well, but it occasionally returns Markdown or cheerful commentary instead of JSON. Validate strictly and retry. Lenient parsing derails the agent loop quietly, and you'll find the bug in production.

4. Assuming the pipeline rotates credentials. A secret scan abort prevents future merges; it doesn't invalidate a token that already leaked. Credential revocation is a separate incident process and has to run outside CI.

5. Designing cloud-only inference. Model API access is not equally reliable everywhere, and demo connectivity predicts nothing. Wire a local provider mode into the agent early, because retrofitting it after a region goes dark is the wrong time to learn.

One Thing to Remember

Every layer of this stack is young. WebMCP's syntax has churned within three months, and consequentialHint landed about two weeks before a conference demo. What's holding is the shape of the stack itself: agents reach user sessions through the browser, merge through DevSecOps gates, draw context from institutional memory, produce shareable artifacts, and run on runtimes that answer to public audit. Build against those boundaries, not against this month's API names.

The Bottom Line

If you're building a web product that agents should be able to drive, expose WebMCP-style tools now: the website stays a website, and the agent gains a structured, authenticated path through the browser session the user already has open.

If you're shipping agent code in a regulated enterprise, install the four-stage DevSecOps gate before the first incident: secrets die at commit time, prompts get audited like source, dependencies get SCA'd, and SAST finishes in about 90 seconds with SARIF landing in the Security tab.

If you're constrained by unreliable cloud access or sensitive data, make local inference a first-class provider mode: Gemini Nano or an Ollama model keeps the whole loop on the machine, and the change is a config entry. Expect WebMCP to stabilize in Chromium around early 2026; that's when browser-native agents stop being demos and start being a procurement decision.