Layered architecture: client to data

Agent Forge is layered by boundaries, not by directory names. The upper layers own identity and protocol; the middle layers orchestrate sessions and tools; the lower layers persist state and reach external systems. Governance APIs and the runtime engine share a deployable service surface, while permission and audit attach at the ingress and data boundaries.

Five layers

flowchart TB
  C[Client SDK / console] --> G[Ingress: HTTP/SSE termination, auth, RequestContext]
  G --> S[Service: session / trigger / governance / observability / config routing]
  S --> R[Runtime: orchestration, Tool, model, sandbox, HITL]
  R --> D[(Data: SQLite or Postgres, audit, observability)]
  R --> L[External: LLM / object storage]

Layer	Responsibility
Client	REST + SSE; carries isolation and role context
Ingress	Auth, identity binding, tenant/owner/model/role into RequestContext, enterprise license gates
Service	API routes and plugin mounts (events, hooks, triggers, `/govern`, and related surfaces)
Runtime	Session orchestration, tools, model gateway, MCP, sandbox, breaker and approval handoff
Data	Migrations, RLS, audit chain, observability, trigger runs, retention policy

Data path: client → ingress (identity / three dimensions / RBAC / license) → routing → engine → storage → response or event stream. For the kernel main path, see end-to-end request lifecycle.

Related reading: