Introducing Synth: On-Demand Agent Tool Synthesis
Every agentic AI framework today works the same way. You pre-register a library of tools: function signatures, parameter schemas, authentication configurations. You maintain those tools as the underlying APIs change. You manage version drift between your tool definitions and the services they wrap. You write integration tests. You update documentation. You spend more time maintaining the tool library than building the agent.
We built OATS because this model is fundamentally backwards. Tools should not be permanent fixtures maintained by engineering teams. Tools should be synthesized on demand, approved by humans, executed in sandboxes, and destroyed when the task is done. That is what OATS does.
OATS — On-demand Agent Tool Synthesis — is built to be self-hosted, with an open-source release planned. It is designed to run as a Python package with no proprietary dependencies, so you own and control the model, data, and identity.
The Problem with Tool Registration
The standard approach to giving AI agents access to external services is tool registration. You define a tool — a function with typed parameters and a description — and register it with the agent framework. The agent sees the tool in its available actions, decides when to use it, and calls it with the appropriate parameters.
This works for small, stable tool sets. It breaks down in practice for three reasons.
First, tool libraries grow without bound. Every new integration is a new tool to maintain. A team that starts with five tools has fifty within six months. Each tool has its own authentication model, error handling requirements, rate limits, and API version dependencies. The maintenance burden scales linearly with the number of integrations, and it never decreases.
Second, pre-registered tools create a fixed capability surface. The agent can only do what you have pre-defined. If a user needs the agent to interact with a service you have not written a tool for, the answer is “wait for engineering to build it.” This creates a bottleneck that defeats the purpose of an autonomous agent.
Third, static tools are security liabilities. A registered tool with database credentials exists permanently, with those credentials embedded or accessible for the lifetime of the tool. The attack surface is persistent. A compromised agent has permanent access to every registered tool and every credential those tools hold.
How OATS Works
OATS inverts the model. Instead of pre-registering tools, you describe what you need in natural language. OATS synthesizes a tool that accomplishes the intent, presents it for human approval, executes it in a sandboxed environment, and destroys it when execution completes. There is no persistent tool library. There is no credential storage. There is no maintenance burden.
Step 1: Intent Description
The user or the orchestrating agent describes what needs to happen in plain language: “Get the last five commits from the main branch of a public GitHub repository.” This is not a function call. It is an intent declaration.
Step 2: Tool Synthesis
The OATS Synthesizer takes the intent description and generates executable code to accomplish it. The Synthesizer is backed by an LLM — OATS supports six providers: Anthropic, OpenAI, Ollama, AWS Bedrock, our platform, and any OpenAI-compatible endpoint. The generated code is constrained by the CapabilityRegistry, which defines what categories of operations are permitted. Built-in capabilities include HTTP requests, GitHub API access, Slack integration, AWS operations, GCP operations, Azure operations, shell command execution, and filesystem access.
Step 3: Human Approval (HITLGate)
Before any synthesized tool executes, it passes through the HITLGate — a mandatory human-in-the-loop approval gate. The reviewer sees the original intent, the generated code, the capabilities it will use, the credentials it will access, and a risk classification. The reviewer approves, rejects, or requests modifications. This gate is not optional. It is a structural component of the execution pipeline that cannot be bypassed through configuration.
Step 4: Sandboxed Execution
Approved tools execute in an isolated subprocess with enforced boundaries. The subprocess runs with a configurable timeout (30 seconds by default). Filesystem access is limited to a temporary working directory. The sandbox validates generated code before execution, rejecting dangerous constructs such as eval, os.system, and __import__. Credentials are injected as environment variables within the subprocess. The sandbox is the same in development and production — there is no separate mode for either environment. When execution completes, the subprocess terminates, the generated code is destroyed, and the environment variables containing credentials cease to exist.
Step 5: Result and Cleanup
The execution result is returned to the orchestrator with a complete audit record: the original intent, the generated code, the approval decision, the execution output, resource consumption metrics, and timing data. The tool no longer exists. The environment variables containing credentials no longer exist — they were scoped to the terminated subprocess. The attack surface returns to zero.
Architecture
The OATS architecture consists of four primary components that form the execution pipeline.
The CapabilityRegistry defines the universe of permitted operations. Each capability represents a category of actions — HTTP requests, GitHub operations, Slack messaging, cloud provider APIs, shell commands, filesystem operations. Capabilities are enabled or disabled through configuration. When a tool is synthesized, it can only use capabilities that are explicitly registered. This is the governance boundary: you control what categories of operations agents can perform, without needing to pre-define every specific operation.
The Synthesizer generates executable code from intent descriptions, constrained by available capabilities. It uses an LLM to translate natural language into working code, applying code generation templates and safety constraints specific to each capability type. The Synthesizer is provider-agnostic — switch LLM providers by changing a configuration parameter.
The HITLGate intercepts every synthesized tool before execution and requires human approval. It presents the generated code, its capability requirements, its credential needs, and a risk assessment classified as LOW, MEDIUM, HIGH, or CRITICAL. Approval decisions are logged immutably. The gate requires human approval for every synthesized tool, with the risk assessment informing the reviewer's decision. When integrated via the MCP server, LOW-risk tools may be auto-approved, but the core gate always requires explicit human authorization.
The Executor runs approved code in an isolated subprocess. It enforces timeout limits and filesystem restrictions, and validates code before execution. It captures stdout, stderr, return values, and execution metrics. Credentials are injected as environment variables scoped to the subprocess. When execution completes — successfully or not — the subprocess terminates and those environment variables cease to exist along with it.
Six LLM Providers, Zero Lock-In
OATS supports six LLM provider backends for tool synthesis: Anthropic (Claude), OpenAI (GPT-4o and successors), Ollama (local open-weight models), AWS Bedrock (managed model access), our platform (a managed inference endpoint), and any OpenAI-compatible API endpoint (vLLM, TGI, LiteLLM, and others).
Switching providers requires changing a single configuration parameter. Your agent logic, capability definitions, approval policies, and execution infrastructure remain unchanged. This is not theoretical portability — it is a configuration change that takes effect on the next tool synthesis request.
Built-In Capabilities
OATS ships with eleven built-in capability categories that cover the most common enterprise integration patterns:
- HTTP: Make authenticated HTTP requests to any REST API
- GitHub: Repository operations, issue management, PR workflows
- Slack: Send messages, read channels, manage threads
- AWS: S3 operations, Lambda invocations, DynamoDB queries, and more
- GCP: Cloud Storage, BigQuery, Cloud Functions, Pub/Sub
- Azure: Blob Storage, Cosmos DB, Azure Functions
- Shell: Execute system commands with configurable restrictions
- Filesystem: Read and write files within sandboxed directories
- JSON: Parse, transform, and generate JSON data
- Datetime: Date and time parsing, formatting, and arithmetic
- Data: Data manipulation, filtering, and aggregation operations
Custom capabilities can be defined for organization-specific services. The capability interface is intentionally simple: a name, a description, a set of permitted operations, and an optional credential provider. This simplicity is deliberate — capabilities define boundaries, not implementations.
Why On-Demand Synthesis Matters
The shift from pre-registered tools to on-demand synthesis is not incremental. It changes the security model, the maintenance burden, and the governance surface of agentic AI systems.
Security: No persistent tools means no persistent attack surface. Credentials exist only for the duration of a single execution. A compromised system has nothing to steal because nothing is stored.
Maintenance: No tool library means no tool maintenance. When an API changes, the synthesizer generates updated code on the next request. There is no version drift to manage.
Governance: Every tool execution is preceded by human review and followed by a complete audit record. There are no pre-approved tools running unmonitored. Every action is explicitly authorized.
OATS is designed to be self-hosted and free to run, with an open-source release coming. Define your capabilities and start synthesizing tools instead of maintaining them.