# Webagent: An Open-Source Framework for Deploying Business AI Agents with Nine Configurable Slots
## Introduction
A new open-source tool has entered the AI agent landscape, offering a streamlined way for businesses to deploy public-facing AI agents without writing complex orchestration code. The framework, written in Go, allows teams to stand up a working agent by simply providing a website URL and filling in a declarative JSON configuration file. With a single command, businesses can launch an agent capable of interacting with customers across multiple channels including Slack, WhatsApp, and HTTP-based interfaces.
The project is the work of Agent-net, a team focused on building an ecosystem where AI agents can discover each other, establish trust, and transact autonomously. Their latest release represents a significant step toward making agent deployment accessible to businesses without deep technical expertise in AI engineering.
## How It Works: The Nine-Slot Architecture
At the heart of this framework lies a modular design built around nine distinct slots, each representing a critical component of an AI agent’s functionality. Every slot exposes a Service Provider Interface with a registry of available providers and a sensible default, giving businesses a menu-driven configuration experience.
The nine slots are:
– **Retrieval** — Determines how the agent accesses information, with options for live fetching, keyword-based search, or hybrid approaches.
– **Memory** — Manages conversation context, with a session-based memory provider as the default.
– **Guardrail** — Enforces safety rules on every action the agent takes, with a basic guardrail enabled by default.
– **Channel** — Defines how the agent communicates with users, supporting A2A (agent-to-agent), web interfaces, Slack, and WhatsApp, with a Telegram adapter in development.
– **Secrets** — Handles sensitive credentials through environment variables, file-based storage, or static values, with a strict naming convention ensuring secrets are never committed directly into configuration files.
– **Presenter** — Controls how the agent formats its responses, offering text output, terminal-based QR codes, or web-based presentation.
– **Model** — Specifies the language model powering the agent’s reasoning, with support for echo mode (for testing), OpenRouter, and a gateway provider.
– **Action** — Defines what the agent can do, with options for no actions, a demo action, or connecting to external tools via the Model Context Protocol (MCP).
– **Observability** — Enables tracing and logging of agent behavior, with support for per-turn trace recording aligned with OpenTelemetry Generation AI conventions.
This design serves three audiences simultaneously: businesses that configure by selecting from the available providers, businesses that extend the framework by registering custom providers, and partner companies that ship adapter modules. Crucially, the core framework remains untouched — no one needs to fork the repository to build on top of it. Every provider must pass a conformance suite to earn certification, ensuring consistency across the ecosystem.
## Safety by Design
One of the most significant architectural decisions in this framework is how it handles agent safety. Rather than relying on prompt-level instructions — which can be bypassed or manipulated — the framework enforces safety at the code level through a mechanism called `action.Guard`.
Every tool available to the agent, whether it originates from the action provider or is injected by the host system, is wrapped so that the chosen guardrail evaluates the action before it executes. The underlying model has no ability to bypass this guard. This means safety enforcement is structural and reliable, not dependent on the model’s willingness to follow instructions.
The design philosophy is grounded in research showing that architectural decisions matter more than model capability when it comes to agent success. The framework’s documentation cites findings that demonstrate a significant gap in task completion rates — with properly architected systems achieving roughly 85% success compared to 50% for less disciplined approaches, even when using the same underlying models.
## What Works Today
The framework is functional out of the box. Two example configuration files — one for a food delivery scenario and another for a bakery business — allow users to validate and serve agents immediately without any API keys or external credentials. The default “echo” brain simply returns the input, making it ideal for testing the full pipeline.
For businesses wanting to use real language models, the framework includes a command-line tool for storing API keys securely in the operating system’s configuration directory with restricted file permissions. The keys are never embedded in the configuration file itself, and environment variables always take precedence, ensuring credentials stay out of version control.
The MCP action provider represents a particularly powerful feature. Any business that already has an MCP server can become an acting agent by adding a single block to their specification. The provider connects using Streamable HTTP, supports both JSON and Server-Sent Event transports, and handles authentication via bearer tokens or API keys. During the validation phase, it performs a handshake with the MCP server and reports the actual number of available tools, giving businesses confidence that their configuration is correct before going live.
The channel adapters for Slack and WhatsApp include robust production features: webhook signature verification ensures incoming messages are authentic, immediate acknowledgment prevents timeout issues, replies are sent through the platform’s official API, the agent ignores its own messages to avoid loops, and duplicate deliveries from retries are automatically filtered out.
## What’s Still in Progress
While the framework is functional, it carries a v0 version label, signaling that several important features are not yet complete. These include a browser action provider that would allow agents to interact with websites that don’t have an MCP server, OAuth-gated MCP support for servers requiring authorization flows, a full OpenTelemetry exporter (though traces are currently OTel-aligned and stored in-process), a Telegram channel adapter (currently a stub), partner memory and guardrail adapters, and the AgentNet identity forwarding and billing layer.
The team recommends that organizations review the deferred-hardening list before deploying to production, particularly for use cases requiring browser-based actions or external payment processing.
## Key Takeaways
– A single JSON specification file with nine configurable slots controls the entire agent behavior
– Every tool call passes through a code-enforced guardrail that the model cannot bypass
– Live capabilities include OpenRouter and gateway language model brains, MCP tool integration, and Slack, WhatsApp, and HTTP channels
– The framework is Apache 2.0 licensed, written in Go, and currently at v0 status
– Secrets are never written into configuration files, and a strict naming convention ensures credentials resolve at build time or fail the entire process
– No forking is required to extend the system — custom providers register through the existing interface
## Frequently Asked Questions
**What programming language is the framework written in?**
The framework is written entirely in Go, chosen for its performance characteristics and strong concurrency support, which are well-suited for handling multiple agent interactions simultaneously.
**Can I use my own language model provider?**
Yes. While the framework ships with echo, OpenRouter, and gateway providers out of the box, the architecture supports registering custom model providers through the slot interface. Any provider that passes the conformance suite can be certified and used.
**How does the framework handle agent-to-agent communication?**
Agent-to-agent communication is supported through the A2A channel type, which allows one agent to discover and interact with another agent. This is part of the broader Agent-net vision of creating a marketplace where agents trust and pay each other.
**Is it safe to use in production right now?**
The framework is labeled v0, which means it is functional but not yet feature-complete. Core safety mechanisms like action.Guard are fully operational, but certain providers — particularly the browser action provider and OAuth-gated MCP — are still under development. The team advises reviewing the deferred-hardening list before production deployment.
**How are API keys managed securely?**
API keys are stored in the operating system’s configuration directory with file permissions set to 0600 (readable only by the owner). Keys are never written into the JSON specification file, and an exported environment variable will always override any configured value. Secret references in the spec use a naming convention (keys ending in “Secret”) that are resolved through the chosen vault at build time.
**What happens if I configure a channel like Slack or WhatsApp but forget to set up the secrets?**
The build process will fail. The framework requires that any Secret references in the configuration resolve through the selected vault, and if a reference cannot be resolved, the build fails rather than starting a channel without proper credentials.
**Can I extend the framework with my own providers?**
Absolutely. The framework is designed with three audiences in mind, one of which is businesses and teams that extend the system by registering custom providers. Each slot has a defined interface, and providers must pass the slot’s conformance suite to be certified.
**What is the significance of the 85% versus 50% success gap mentioned in the design documentation?**
This figure comes from research cited in the framework’s design documents, illustrating that how an agent is architected — particularly how safety is enforced — has a far greater impact on success rates than the capabilities of the underlying model. A well-architected system using the same model can more than double task completion rates compared to a poorly architected one.
## Conclusion
This open-source framework represents a meaningful advance in making AI agent deployment accessible to businesses. By abstracting away the complexity of orchestration and replacing it with a declarative configuration approach, it lowers the barrier to entry significantly. The nine-slot architecture provides enough flexibility for diverse use cases while maintaining a consistent and certifiable standard across providers.
The emphasis on code-enforced safety rather than prompt-based safety is a particularly noteworthy design choice, reflecting a growing understanding in the AI community that reliability comes from architecture, not just model intelligence. With live support for major messaging platforms, MCP integration, and a clear roadmap for future features, the framework offers a compelling foundation for businesses looking to deploy AI agents in the near term.
As with any v0 software, teams should carefully evaluate the deferred features against their production requirements, but for use cases that align with the currently available providers, the framework delivers a practical and well-engineered solution.
Thank you for reading
