Agents

An agent in AKOS is not just a prompt. It is a small, typed, configured worker — and every part of it is inspectable and governed at runtime.

Anatomy

┌─────────────────────────────────────────────────┐
│  Agent                                          │
│  ┌──────────┐  ┌──────────────┐  ┌───────────┐ │
│  │  Model   │  │ Instructions │  │   Tools   │ │
│  │ (any of  │  │  system      │  │ allowlist │ │
│  │ 30+ LLM  │  │  prompt +    │  │           │ │
│  │ adapters)│  │  role        │  └───────────┘ │
│  └──────────┘  └──────────────┘                │
│  ┌──────────────────┐  ┌────────────────────┐  │
│  │  Context (RAG)   │  │ Identity +         │  │
│  │  scoped knowledge│  │ permissions (DID)  │  │
│  └──────────────────┘  └────────────────────┘  │
└─────────────────────────────────────────────────┘

Model

Any of 30+ LLM adapters inherited from the AgentsKit upstream: Anthropic, OpenAI, Gemini, Bedrock, Azure, Mistral, Groq, vLLM, Ollama, and more. The model is a per-agent config value — swap providers without rewriting the agent or the flow it belongs to. Ollama and vLLM run fully local, enabling air-gapped deployments that never call a cloud API.

Instructions

A system prompt plus a role description. This is the agent's persistent context — what it knows about itself, its task, and the constraints it should follow.

Tools

An explicit allowlist of capabilities the agent may call. An agent cannot call a tool that is not on its list. Tool kinds include:

• Search — web search or knowledge-base lookup
• HTTP — outbound API calls (subject to the workspace egress allowlist)
• File IO — read or write files within the sandbox boundary
• Code execution — run code inside the isolated sandbox
• RAG — retrieve from the agent's knowledge sources
• SaaS connectors — Slack, GitHub, Linear, Stripe, and others (require a connected OAuth integration)

Context (RAG)

Each agent carries a set of knowledge sources it can retrieve from. Retrieval is permission-scoped: an agent only retrieves content its principal's role is allowed to see. The built-in RAG pipeline includes a chunker, embedders, a vector store (pgvector in cloud mode, in-process SIMD in local mode), and a reranker.

Identity and permissions

Every agent has a signed identity — a Decentralized Identifier (DID). It never acts as itself; it always acts on behalf of a principal (a human user or a service account). Every action is checked against the principal's role and capability set via RBAC before the handler runs. Every action is written to the signed audit ledger with the principal as the subject, so accountability is always traceable.

Everything is data

An agent definition is a typed config object. You can edit it three ways — all equivalent, never diverging:

What an agent cannot do

• Call a tool not on its allowlist.
• Access knowledge outside its RAG scope.
• Make a network call to a host not on the workspace egress allowlist.
• Bypass the capability check that guards every RPC handler.
• Leave the sandbox boundary when running code or shell commands.

These constraints are enforced at the runtime layer — they are not advisory rules.