The problem it addresses
Getting one agent to work is a weekend. Running agents where the cost of a mistake is real is a different problem, and it is mostly not a modelling problem:- An agent acts with someone’s authority. Which someone, and how far does it extend?
- Model output is untrusted input. It arrives as a shell command or a tool call.
- Agents are long-running and stateful. A process crash mid-task should not lose the task.
- When something goes wrong, someone will ask what happened and why it was allowed.
What it gives you
Isolation by construction
Every entity belongs to a workspace, and repositories cannot be built
without a user context. Scoping is structurally hard to omit rather than a
rule developers must remember.
Relationship-based authorization
Permissions come from relationships in a graph — this user manages this
project, this project contains this agent — evaluated by OpenFGA or Ory
Keto. Checks fail closed.
Sandboxed execution
Commands and skills run in isolated sandboxes managed by a dedicated Go
service, not in the workflow process. Logs and artifacts go to object
storage and are referenced by handle.
Durable workflows
Agent execution is a Temporal workflow. A worker restart does not lose a
task, and a run can wait on a human approval for as long as it takes
without holding a connection open.
Governed tool access
Tool calls pass an interceptor pipeline — budget gates, security filters,
observers — before they run, and the same policy that decides what an agent
may call decides what it is even shown.
MCP as the tool interface
External tools connect over the Model Context Protocol, hosted by AgentArea
or connected remotely, with secrets resolved server-side.
How the pieces fit
The split matters: the control plane decides and records, the data plane executes and holds payload. That boundary is what lets execution move into your own network while the platform stays where it is. How it works follows a single request across it.The stack
Why not an agent framework?
If you are building one agent, or embedding agent behaviour into an existing service, a framework is the right tool and this is too much machinery. The trade happens when agents start acting on behalf of other people. A framework gives you the loop and leaves isolation, authorization, durability, and audit as integration work — which is where the effort actually goes, and where getting it subtly wrong is expensive. AgentArea makes those the platform’s job, at the cost of being something you operate: four processes, a database, a workflow engine, and an authorization service. That cost is only worth paying if the governance is worth something to you. If it is not, use a framework.Limits
Worth knowing before you invest time.Where to go next
Start here, in order:Run AgentArea locally
The development stack, from clone to a dashboard.
Quickstart →
Read how it works
The request path, and what each service does. Read this before the rest of
the documentation; it makes the rest legible.
How it works →
Create and configure an agent
Give an agent a model and run a task.
Create and configure →
Agentic networks
The network model, and which parts of it are enforced.
Workspaces, projects, and resources
The scoping model everything else assumes.
Control plane and data plane
Where your data goes, and how to keep it in your network.
Open core
What is core, what is commercial, and how the boundary is implemented.
Self-host requirements
Running it somewhere other than your laptop.
API reference
Every endpoint, generated from the OpenAPI spec.
License and community
Apache License 2.0. Commercial features exist as a separately installed package; see Open core for exactly where the line falls.GitHub
Source, issues, and discussions.
Discord
Ask questions and follow development.