The Slogan Simplifies the Problem
Agent-net presents Webagent as an open source Go harness that can turn websites into public-facing business agents. That description captures the desired outcome, but hides an important condition: the framework does not currently inspect an arbitrary website, infer its workflows, and operate every part of it automatically. Instead, a business defines a declarative JSON specification, selects providers for the agent’s capabilities, and runs `webagent serve`.
The center of the agent is a Brain, meaning an LLM plus instructions, surrounded by pluggable capabilities such as actions, retrieval, and communication channels. These capabilities are expressed as service provider interfaces, with providers registered through a registry rather than embedded in the core. Building an agent therefore becomes a matter of selecting implementations, replacing adapters, and satisfying interface contracts instead of maintaining one-off orchestration code.
The Architectural Bet Is action.Guard
Webagent’s most consequential choice is not the number of models it supports, but the execution pipeline that the model cannot bypass. Every tool, whether supplied by the action provider or injected by the host, is wrapped by `action.Guard`. The selected protection mechanism runs before the action executes. The model can request an action, but it cannot jump around the code-level boundary.
That is a different security assumption from telling a model in its system prompt not to perform dangerous operations. Prompt-based control depends on the model interpreting and continuously obeying the instruction, while Guard places the checkpoint immediately before execution. The research cited by the project points to the same broader issue: with the same models, architecture can produce a task-success gap of roughly 85 percent versus 50 percent. Success here is not merely producing a good answer. It is completing a task reliably while tools, permissions, and failure paths are all in play.
Start with an MCP Service, Not a Browser
The most practical path into Webagent today is to wrap an existing MCP service as a public-facing business agent. The MCP action provider connects over Streamable HTTP, supports JSON and SSE, and accepts bearer-token or API-key authentication. It performs the handshake during the build process and exposes the actual tools to the agent, allowing `validate` to report the real tool count. That is more inspectable than merely claiming in a configuration file that certain tools should exist.
The project also includes adapters for Slack, WhatsApp, and HTTP. The Slack and WhatsApp adapters verify inbound webhook signatures, acknowledge requests immediately, ignore messages sent by the agent itself, and de-duplicate retries. Secrets are not placed directly in the specification. Configuration keys ending in `Secret` are resolved through the selected vault at build time, and an unresolved reference prevents the channel from starting. These details show attention to real integration boundaries, but they do not mean that arbitrary websites can already be operated automatically.
A Passing Example Is Not a Completed Loop
Webagent ships with two examples, `zomato.json` and `bakery.json`, using a credential-free echo brain and offline demo action providers. They can run `validate` and `serve` without network access or external credentials. That is useful for framework development: a team can inspect specification parsing, provider assembly, tool guarding, and local channel flows before configuring a real model or service. But it proves that the scaffold and local execution path work, not that live models, real tools, and every communication channel are ready.
The project is still labeled v0. The browser action provider, OAuth-protected MCP, OpenTelemetry exporter, and AgentNet identity and billing layers are listed as unfinished, while some example channels remain stubs. A sensible evaluation path is to connect an existing MCP service first, inspect the `validate` output, confirm Guard coverage, test secret resolution, webhook retries, and failure behavior, and only then consider exposing production actions. Webagent’s value is that it makes these questions explicit rather than pretending they have disappeared.