AgentField: A Control Plane That Turns Agent Functions into Callable APIs
Build, run and scale AI agents like API and microservices
At a glance
- What is it?
- AgentField is an open-source Go-based control plane for building AI agents as REST endpoints, with fan-out, queues, retries, and tracing. It targets developers who want to move from prototype agents to production multi-agent backends without writing glue code.
- Who is it for?
- Adopt AgentField if you are building multi-agent systems that need to be callable by frontends, backends, or cron jobs, and you want to avoid manual queue and retry plumbing. Skip it if you prefer to keep your agent logic tightly coupled to a specific model provider's SDK, or if you need fine-grained control over the underlying orchestration without a control plane in between.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem AgentField Solves
Most AI agent code lives inside a single script or notebook. It works for a demo, but when a frontend or another service needs to trigger an agent, you end up writing an HTTP wrapper, a queue, retry logic, and some tracing. AgentField is a control plane that does that work for you. It takes agent logic written in Python, Go, or TypeScript and exposes every function as a REST endpoint. The README states that one request can fan out to thousands of agents, with the control plane handling queues, retries, and traces for every branch. This is aimed at teams that want to treat agents as internal microservices: callable by any service in the stack, including other agents and cron jobs. The pitch is that you write plain functions, no DSL or graph wiring, and get production infrastructure in return.
How the Control Plane Works
The core mechanism is visible in the Python example. You define an Agent with a node_id and a version. Inside a reasoner function, you can call app.ai for a model completion, and app.call to invoke another function on the same agent through the control plane. The README shows a recursive research agent: it breaks a question into sub-questions, fans out with asyncio.gather, and each branch calls the same agent at a greater depth. A depth cap keeps the fan-out bounded. The control plane is what routes those nested calls, queues them, retries failures, and traces the execution. The final app.run() exposes a REST endpoint: POST /api/v1/execute/researcher.research. That means the control plane sits between your code and the HTTP layer. It is not a library you import for orchestration; it is a separate process that manages execution. The installer sets up a Docker Compose stack that includes the agent, the control plane, and a production-ready REST API endpoint.
Getting Started: Installer and First Spec
The README's quick start is a single curl command: curl -fsSL https://agentfield.ai/install.sh | bash. This installs the af CLI into ~/.agentfield/bin, and optionally a coding harness called aforge. On macOS, the installer registers the control plane to start at login via launchd and adds a menu-bar icon. You can stop it with af service stop, and check health with af service status. To build an agent, you paste a spec into a coding agent like Claude Code or Codex using the /agentfield command. For example: /agentfield Build a claims processor with risk scoring, pattern detection, and human approval for low-confidence decisions. The system generates a Docker Compose stack with the agent, control plane, and a REST endpoint you can curl. The installer also allows skipping the harness with --no-aforge and skipping the tray icon with --no-tray. This is a prompt-to-production workflow, but it relies on the coding agent interpreting the spec correctly. The README does not detail what happens when the spec is ambiguous or the generated stack fails to start.
The Developer Experience: Plain Functions, No DSL
The selling point is that you write ordinary functions. The Python example uses a standard async function with pydantic models for structured output. There is no YAML for graph wiring and no custom DSL. The Agent class decorates a function with tags and exposes it. The AIConfig lets you specify a model, here anthropic/claude-sonnet-4-20250514. The app.ai call takes a system prompt, user message, and an optional schema for structured responses. The app.call method is how you invoke another function on the same agent, and it goes through the control plane. This design keeps the code readable, but it also means the control plane must understand the semantics of your function calls. The README claims no timeout setup, no broker, no queue setup. That is a strong claim. The control plane abstracts those concerns, so you do not configure them, but you also cannot tune them per call unless the SDK exposes that. The README does not show configuration options for retries, timeouts, or queue priorities.
Real Limitations and Failure Modes
The README is clear that a plain kill on macOS looks like a crash and the control plane restarts. That is a deliberate resilience feature, but it can surprise you if you are trying to stop the service for maintenance. You must use af service stop. That is a concrete operational constraint. Another limitation is the dependency on a specific model provider. The example hardcodes anthropic/claude-sonnet-4-20250514. If you want to switch models, you either change the AIConfig or pass a model parameter to app.ai, as the example does for recursive calls. But the control plane's queue and retry behavior is model-agnostic. The bigger limitation is that the README only demonstrates a single pattern: recursive fan-out. It does not show how to handle stateful agents, human-in-the-loop approval flows, or long-running workflows. The claims processor example mentions human approval for low-confidence decisions, but the code is not shown. If your agent needs to pause and wait for a human, the control plane must support that. The README does not document that feature. Also, the version is still in release candidate stage (v0.1.138-rc.16), which suggests the API may change.
Alternatives: Comparing Approaches
The most direct alternative is to build your own HTTP service around an agent framework like LangChain or LlamaIndex. That approach gives you full control over routing, queues, and retries, but it requires you to write that infrastructure yourself. AgentField replaces that glue code with a control plane. Another alternative is to use a managed agent platform like Google's Vertex AI Agent Builder or AWS Bedrock Agents. Those are closed-source and tie you to a cloud provider. AgentField is open source under Apache-2.0 and can run on your own infrastructure, including Kubernetes, given the topic tags. The key difference is that AgentField treats agents as functions that the control plane calls, whereas frameworks like LangChain give you primitives to build the orchestration logic in your code. With AgentField, the orchestration is implicit in the control plane's routing. That is a trade-off: less code, but less visibility into how the control plane makes decisions. The README says the control plane traces every branch, so you get observability, but you do not get to change the scheduling algorithm.
Maintenance and Upgrade Cost
The project is actively developed, with three release candidates pushed on the same day (v0.1.138-rc.14, rc.15, rc.16). That cadence can be a double-edged sword. You get fixes and features, but you also have to track changes. The README does not include a changelog or migration guide. The installer script will likely update the CLI, but the Docker Compose stack is generated per project, so upgrading the control plane may require regenerating or updating that stack. The Apache-2.0 license means you can fork and modify the control plane, but that is a maintenance burden you take on yourself. The project also includes a coding harness (aforge) that may have its own release cycle. If you rely on the /agentfield prompt workflow, you depend on the coding agent correctly interpreting the spec and the generated code being up to date with the SDK. The README does not specify whether the generated code is pinned to a particular SDK version. Before adopting, check the release notes for breaking changes, and test the upgrade path on a non-production stack.
Editorial conclusion
Adopt AgentField if you are building multi-agent systems that need to be callable by frontends, backends, or cron jobs, and you want to avoid manual queue and retry plumbing. Skip it if you prefer to keep your agent logic tightly coupled to a specific model provider's SDK, or if you need fine-grained control over the underlying orchestration without a control plane in between. Before adopting, verify the stability of the release candidate channel (v0.1.138-rc.x) and check whether the installer's launchd registration on macOS fits your deployment environment. Confirm that the Python, Go, and TypeScript SDKs cover the exact agent patterns you plan to use, since the README only demonstrates a recursive fan-out example.
Community notes