System Architecture

Runtime layers, control flow, and execution boundaries.

System Architecture

AgentWorld is built as a layered runtime.

Each layer has a narrow responsibility. This keeps model behavior flexible while keeping business behavior predictable.

Runtime layers

+--------------------------------------------------+
| Interface layer                                  |
| API, dashboard, webhooks, event sources          |
+--------------------------------------------------+
| Control plane                                    |
| routing, queues, policy checks, scheduling       |
+--------------------------------------------------+
| Agent runtime                                    |
| planning, reasoning, tool selection, handoffs    |
+--------------------------------------------------+
| Tool adapters                                    |
| SaaS APIs, internal services, data connectors    |
+--------------------------------------------------+
| State layer                                      |
| tasks, memory, logs, approvals, artifacts        |
+--------------------------------------------------+
| Solana execution layer                           |
| wallets, transactions, settlement, attestations  |
+--------------------------------------------------+

Layer responsibilities

The interface layer ingests demand. That demand can come from users, scheduled jobs, partner systems, or market events.

The control plane turns inbound demand into executable work. It assigns workflow IDs, applies policy, enqueues jobs, and decides whether an action can run automatically or requires review.

The agent runtime performs bounded reasoning. It evaluates task context, chooses tools, writes outputs, and emits handoffs. It does not own final authority for policy-sensitive actions.

The tool layer isolates side effects. Every connector should expose a narrow contract with typed inputs, known failure modes, and clear scopes.

The state layer keeps the system durable. This includes run records, task graphs, memory objects, approval events, and execution artifacts.

The Solana layer handles value transfer and verifiable finality. It is the place for treasury actions, settlement events, and policy-bound signatures.

Execution path

A normal run follows this shape:

1. An event enters the system.

2. The control plane resolves the matching workflow.

3. Policy determines whether the task can execute.

4. The runtime invokes the selected agent.

5. The agent reads scoped state and calls tools.

6. State transitions are persisted after each material step.

7. If money or final approval is needed, the Solana layer is invoked.

8. The system reconciles outcomes and closes the task.

Execution envelope

Every run should be reducible to a compact envelope.

{
  "run_id": "run_01",
  "workflow": "invoice-collection",
  "trigger": "payment_due",
  "agent": "collections-agent",
  "policy_context": "medium-risk",
  "memory_scope": ["customer", "invoice", "account"],
  "allowed_tools": ["crm.read", "mail.send", "payments.request"],
  "budget": {
    "tokens": 20000,
    "spend_usd": 50
  }
}

The envelope matters because it makes execution inspectable before the model starts reasoning.

Synchronous and asynchronous work

Not every business action should run in one request.

• Synchronous paths fit low-risk actions like classification, triage, or small data enrichment.

• Asynchronous paths fit planning, approvals, multi-step fulfillment, and any operation touching treasury.

The architecture favors asynchronous execution because businesses are queues, not chats.

Event-first design

AgentWorld is easier to scale when state changes emit events.

A tool call can emit artifact.created. A policy check can emit approval.requested. A confirmed transfer can emit settlement.finalized. Downstream agents subscribe to those events instead of polling hidden state.

This produces cleaner handoffs and fewer race conditions.

Failure boundaries

Each layer should fail independently.

A model timeout should not corrupt the task graph. A tool outage should not invalidate approval history. A failed onchain submit should not erase the intent that created it. The control plane should always know whether the system is retrying, blocked, awaiting approval, or complete.

The most important architecture choice is strict separation between reasoning, policy, and settlement.