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. The three are deliberately opposed: Bodha argues for what should be created, Dharma for what must be preserved and kept safe, Tapas for what should be removed. They run at the same time, not in sequence, and they advise — the orchestrator decides. It runs conditionally, not on every message.

BODHA Creation · What to build
COUNCIL
DHARMA Preservation · What to protect
TAPAS Destruction · What to cut
Bodha — the Creator
What should be created?
Bodha argues for what should be built or extended to reach the goal — including recommending a brand-new agent when nothing on the roster covers the job.
How it is actually constrained Its prompt forces the goal through four named lenses before it may propose anything:
  • FORM — what structure or architecture is missing?
  • FLOW — what sequence or pipeline is needed?
  • FUNCTION — what tool or agent capability does not exist?
  • FUTURE — what will this need three steps from now?
It must first check the live platform inventory and may only propose creation when genuinely nothing already serves the need. It returns JSON, not prose: what_to_create[], agents_to_spawn[{agent, reason, task}], routing_hint{subtask → tier} and routing_deps{subtask → [deps]} — that last field is the dependency graph the executor later runs.

Its authority is capped in the prompt itself: it cannot write files, cannot run shell, and its gate_verdict is restricted to allow or warn — Bodha can never block. Creation proposes; it does not get a veto.
Dharma — the Preserver
What must not break?
Dharma is the counterweight to Bodha: where Bodha wants to build, Dharma asks what that build puts at risk and what must be preserved first.
How it is actually constrained Rather than free-form worrying, Dharma must classify the threat into exactly one of ten named descent modes, each bound to a specific failure pattern — matsya (knowledge about to be lost → save it), kurma (system under load → slow down), varaha (data buried or corrupted → restore), narasimha (a rule exploited through a loophole), vamana (scope creep → measure and contain), parashurama (repeated violations → rebuild), rama (a clear correct path exists → follow it), krishna (multi-agent conflict → strategy over force), buddha (the goal itself is wrong → reframe it), kalki (systemic failure → tear down and rebuild). Naming the mode forces a diagnosis instead of a vague objection.

Its gate rules are hard-coded conditions, not judgement calls:
  • threatens existing functionality → block · preserve_existing_files
  • destructive shell command proposed → block · no_destructive_shell
  • scope creep detected → warn · scope_limit_20_lines
  • everything aligns → allow · righteous_path_clear
Dharma is the sentinel that can actually stop things — and it still cannot modify anything itself. It only constrains what the orchestrator is permitted to do.
Tapas — the Destroyer
What should be removed?
Tapas argues for subtraction — catching dead code, redundant steps and stale logic instead of piling more on top of them.
How it is actually constrained Every component gets three tests: does it still serve its original directive, has it been used recently enough to earn its place, and does it add complexity without proportional value.

The interesting part is the safeguard against over-pruning. The prompt requires it to distinguish DEAD from DORMANT: dead means superseded or broken beyond repair and can be flagged; dormant means deliberately idle — a GPU backend waiting for a machine to connect — and must be left alone unless it has sat unused for 30+ days with no activation plan. Recently-created work may never be flagged as decay unless it is genuinely broken, and there is an explicit self-improvement exception: work that makes the system smarter counts as growth, not decay.

Nothing may be flagged without naming what is destroyed, its downstream dependencies, the specific cut, and what replaces it. Its gate blocks on one condition — if output contains hallucinated paths, placeholders or TODOs → block · no_placeholders. That is the check that stops invented file paths reaching you as if they were real.
Verdict
Three views in. One decision out.
Each sentinel returns a stance, its reasoning, a recommendation and a confidence score — plus structured fields specific to its job: what to create from Bodha, what to cut from Tapas, which preservation mode from Dharma. The orchestrator merges those into one routing plan. This is not a vote that resolves itself: the council has no authority to act, and the orchestrator is the only place a decision is made.
Bodha → cloud_2 Dharma → cloud_2 Tapas → groq
Each can run on a different model — the council is model-agnostic, so the review can sit on cheap fast backends while the expensive one does the real work.
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.