Platform Architecture

The system behind
every response.

Agent Forge connects request understanding, retrieval, evidence-aware routing, conditional review, execution, and traceable feedback. The exact path depends on task requirements and the services currently available.

Follow the Request →See Workflows
Decision Flow, In This Page

Three systems.
One pipeline.

Every request touches intake and (when configured) memory before it reaches a backend. Karma decides which backend; Trimurti decides whether it needs deliberation first; Memory decides what context it starts with. The full six-stage breakdown is on the homepage — below is how the three architectural pieces fit into it.

01Intake + Memory Probe 02Karma ranks candidates 03Trimurti reviews, if warranted 04Execute + trace
System 01

Karma System

Karma is the platform's routing-evidence layer. It combines recorded outcomes with health, latency, capability, provider-limit, and exploration signals. It informs candidate ranking; it does not retrain or modify provider models.

1
Task State Record
Routed work can generate a task-state route record containing backend, model, latency, outcome, and task tags. These records provide evidence for later routing.
TaskStateRouteRecord(backend, model, latency_sec, success, tags)
2
Eligibility + Capability
Only compatible candidates are considered. Declared capabilities and task tags help distinguish code, tools, reasoning, vision, context, and speed requirements.
request requirements → compatible candidates
3
Live Operating Signals
Health checks, provider cooldowns, current rate limits, latency, and recent errors can change which eligible backend should receive work now.
health + limits + latency + error evidence
4
Persisted Evidence
When MongoDB Atlas is configured, routing evidence and related state can persist across normal service restarts and deployments, subject to database retention and backup policy.
routing evidence → configured persistence backend
5
Ranking + Exploration
Observed evidence adjusts seeded preferences, while bounded canary work gives compatible zero-sample models a way to gather evidence instead of being excluded forever.
seed prior + evidence + bounded exploration → rank
Routing inputs — how ranking weighs evidence
Declared capabilityeligibility
task fitrequired interfaces
Provider healthlive
reachablerecent errors
Current limitsdynamic
rate budgetcooldown
Observed qualitytask-specific
ratingsoutcomes
Measured latencyrolling
recent callstimeouts
Explorationbounded
zero-sample canarypolicy-limited
Illustrative weighting — not a live telemetry feed.
Recognized-task fast path
Repeated successful task shapes can use cached routing when similarity, confidence, and policy checks permit. New, ambiguous, or high-risk work remains eligible for deeper review.
configuration-dependent · traceable · policy-bounded
System 02

Trimurti Council

Trimurti is a three-perspective review layer for work that warrants additional deliberation. Bodha examines intent, Dharma checks correctness and constraints, and Tapas considers depth and effort. It runs conditionally — not on every message.

BODHA Insight · Analysis
COUNCIL
DHARMA Correctness · Ethics
TAPAS Depth · Effort
Stage 1 — Bodha
What is really being asked?
Bodha deconstructs the request — peeling away surface wording to find the actual intent. Is this a planning task or an execution task? Does it need reasoning depth or speed? What capabilities does it truly require?
Stage 2 — Dharma
What is the right way to answer?
Dharma evaluates correctness constraints. Does this require web search grounding? Does it need code execution verification? Are there safety or scope boundaries? Which backend has the highest fidelity for this class of response?
Stage 3 — Tapas
How much effort does it warrant?
Tapas scores task complexity and decides resource allocation. Should this be a single-shot response or a multi-step agentic loop? Does it need Trimurti deliberation at all — or has Karma already seen this exact pattern?
Verdict
All three vote. Consensus routes.
Votes are weighted by Karma strength for the identified capability. When all three agree, fast execution. When they diverge, the highest-confidence vote with strongest Karma backing wins.
Bodha: cloud_2 Dharma: cloud_2 Tapas: groq
System 03

Memory Architecture

Agent Forge separates durable application state, semantic retrieval, session history, checkpoints, and routing evidence. Production persistence uses MongoDB Atlas; retrieval behavior depends on the configured backend and embedder status.

Vector Retrieval Configured embedder
When vector retrieval is enabled, eligible content can be embedded and searched by semantic similarity through Atlas Vector Search. The active embedder and index dimensions are set per deployment.
Atlas Vector Search · semantic retrieval · runtime status
Sessions + Projects Durable context
Chat sessions, project conversations, files, and thread checkpoints maintain the working context needed to resume tasks. Access remains bound to the authenticated owner and applicable tenant rules.
chat sessions · projects · checkpoints · ownership
MongoDB Atlas Structured + Vector
MongoDB Atlas is the production persistence target for sessions, projects, traces, approvals, routing evidence, and related platform state. Retention and availability follow the configured Atlas deployment.
structured records · vector indexes · production persistence
Retrieval Backends Environment-specific
The platform contains retrieval abstractions and diagnostics for different environments. Atlas is the production choice; local alternatives are optional development paths and are not required for the cloud-first runtime.
Atlas production · optional local development backends
Routing + Review State Evidence and caches
Routing evidence, review outcomes, signatures, and caches can shorten repeated safe paths. Cache hits still pass confidence and policy checks, and never replace the durable source record.
Karma evidence · Trimurti state · task signatures
How Vector Search Works
Eligible content is converted by the active embedder into a vector representation when semantic retrieval is enabled.
Atlas Vector Search returns semantically related records from indexes configured for the active embedding dimensions.
Selected results may be added to the request context after ownership, relevance, and retrieval checks.