Nagent — Technologies & Systems

Nagent in one sentence

Nagent is an operating system for autonomous AI workers.

Every agent you build, every agent you buy off the marketplace, every agent in our applied GTM stack — all of them inherit, by default and without extra wiring:

• Shared memory (Smriti) so they don't forget what happened
• Feedback learning (Karmic) so they get better over time
• Governance so an operator can pause, demote, or audit them
• Observability so a CTO can see what they're doing right now
• Multi-agent orchestration so they can hand off to each other

This is the operating system. Everything else in this document is a component you can build on top of it — or buy ready-made from the marketplace and have running by lunch.

                              ┌─────────────┐
                              │   OPERATOR  │
                              │  (you/team) │
                              └──────┬──────┘
                                     │  Chat · Workbench · Topology
                              ┌──────▼──────┐
                              │    MIRA     │  ← orchestrator chat
                              └──────┬──────┘
                                     │
                          ┌──────────┼──────────┐
                          │          │          │
                      ┌───▼──┐  ┌────▼───┐  ┌───▼────┐
                      │ NORA │  │ Sales  │  │ Content│  ← applied agents
                      │      │  │ Assist │  │ Studio │     (200+ marketplace)
                      └───┬──┘  └────┬───┘  └───┬────┘
                          │          │          │
                          └──────────┼──────────┘
                                     │  Tool calls
                              ┌──────▼──────┐
                              │    ACTION   │  ← 800+ tools
                              │   REGISTRY  │     (Composio + native)
                              └──────┬──────┘
                                     │
        ┌────────────────────────────┼────────────────────────────┐
        │                            │                            │
   ┌────▼────┐                 ┌─────▼──────┐              ┌──────▼─────┐
   │ SMRITI  │ ← memory        │   KARMIC   │ ← feedback   │ GOVERNANCE │
   │ fabric  │   every entity  │  outcome   │   trust      │  ladder +  │
   │ shared  │   remembers     │ attribution│   scoring    │  audit     │
   └─────────┘                 └────────────┘              └────────────┘
        │                            │                            │
        └────────────────────────────┼────────────────────────────┘
                                     ▼
                              ┌─────────────┐
                              │  AUDITLOG   │  ← every write op,
                              │  365 days   │     immutable, evidentiary
                              └─────────────┘

The rest of this document drills into how each piece works and how they compose into systems no individual operator could run by hand.

How to read this document

This is the long-form architectural narrative of what Nagent actually is and how it's put together. It's written for engineering leaders, technical buyers, and operators who want to understand the substrate before buying into the headline. There is no marketing copy here; every system named below is in production today unless explicitly marked.

The document is organised in nine layers, top-down from the substrate that gives every agent its trust properties to the application layer where revenue work happens.

1. The category — what came before

Most "agentic AI" products on the market today fall into three buckets:

Conversational AI / copilots — ChatGPT, Claude, vertical assistants like Sierra and Decagon. These are excellent at single-turn helpfulness and at carrying a chat over a single session. They have no durable memory across threads, no governance layer, no feedback loop that improves the agent over time, and (critically) they don't do work — they suggest, and a human executes.

Agent frameworks for builders — LangChain, CrewAI, AutoGen, LlamaIndex. These give engineers a toolkit to wire agents together, but they are libraries, not platforms. The team that adopts them must build the memory layer, the governance gate, the audit log, the observability stack, the deployment surface, the integration plumbing, and the operator UI themselves. Twelve months of engineering and an ML team later, you have something that resembles the substrate Nagent ships out of the box.

Vertical SaaS with AI bolted on — Most "AI-powered" CRMs and support tools. The AI is a thin layer over the existing schema; the agents can't be composed, can't be governed at the agent level, can't share memory with other agents in the org, and almost always operate at the lowest autonomy band (suggest, don't act).

The gap that all three share is the trust substrate: a memory layer agents share, a feedback loop they answer to, and a governance layer operators control. Nagent is built around that substrate.

2. Nagent architecture at a glance

Most AI systems today operate as isolated assistants — a chat box wired to a foundation model, with prompt engineering as the contract between the user and the system. Nagent is designed as an agentic operating system: autonomous AI workers share persistent memory, inherit governance, coordinate through a runtime, and operate as fleets under operator supervision.

The architecture has nine layers, with enterprise-readiness guarantees enforced across all of them.

┌──────────────────────────────────────────────────────────────────────┐
│  9. Education & Adoption ─ ETIA · HelpHint · AIHelp · Tip Emails     │
├──────────────────────────────────────────────────────────────────────┤
│  8. Ingredient Layer     ─ AI Models · Tools/MCP · Data · Integrations │
├──────────────────────────────────────────────────────────────────────┤
│  7. Observability        ─ AuditLog · Troubleshoot · Decisions Ledger │
├──────────────────────────────────────────────────────────────────────┤
│  6. Content + Brand      ─ Brand Workspaces · Content Studio · Lock  │
├──────────────────────────────────────────────────────────────────────┤
│  5. Ops Layer            ─ MIRA · NORA · Multi-agent Managers        │
├──────────────────────────────────────────────────────────────────────┤
│  4. Application Layer    ─ Marketplace · Agent Stacks · Skills       │
├──────────────────────────────────────────────────────────────────────┤
│  3. Runtime              ─ Orchestration · Debates · Topology · Triggers │
├──────────────────────────────────────────────────────────────────────┤
│  2. Agent Studio         ─ No-code Builder · Canvas · Helix · BuildCraft │
├──────────────────────────────────────────────────────────────────────┤
│  1. Agentic Substrate    ─ Smriti · Karmic · Governance · Audit      │
└──────────────────────────────────────────────────────────────────────┘
   ── enforced everywhere: Enterprise Readiness (scalability ·
      multi-tenant isolation · security · rollback · approval chains)

How the layers compose:

• Lower layers (1–3) provide trust + execution primitives. The Agentic Substrate is the memory, governance, and audit fabric every agent inherits without rebuilding it. Agent Studio is where new agents and multi-agent workflows are designed. The Runtime is the execution engine that coordinates fleets safely.

• Middle layers (4–6) compose operational intelligence. The Application Layer is where marketplace agents, agent stacks, and reusable skills live as deployable operational capabilities. The Ops Layer is where multi-agent managers like MIRA and NORA supervise fleets and route work across specialist agents. The Content + Brand Layer keeps creative output workspace-isolated and brand-safe.

• Upper layers (7–9) provide operator visibility, capability composition, and organisational adoption. Observability surfaces every decision, action, and handoff in real time. The Ingredient Layer is the modular composable capability surface — foundation models, tools, MCP servers, data systems, and integrations — that every agent execution path draws from. Education & Adoption is the organisational enablement infrastructure that turns the platform into an operating habit.

This stack — substrate at the bottom, operator surfaces at the top, ingredients underneath — is what makes Nagent infrastructure for autonomous AI teams, not just an AI agent builder.

A note on access: layers 1–6 ship as a unified platform behind login on the Nagent control plane (the operator + admin surface). Marketplace browsing, public agents, the proposal composer, and the Agentic AI Readiness Index are accessible without login; the full Agent Studio + Runtime + Topology are paid-customer surfaces inside the platform.

3. A day in the life — one operator runs a marketing team

Before going deeper into the stack, here is one concrete example of what Nagent does in practice. A single marketing operator at 9:15 am opens MIRA and types:

"Launch the Q2 outreach campaign to D2C founders in fintech. Run it through end of next week, cap spend at $200/day, route everything to the same booking link."

What happens behind that one sentence:

1. NORA (outbound prospecting agent) reads the operator's saved ICP profile, expands the title set ("D2C founder" → fintech ops leads, payments PMs, growth heads), and queries ContactOut for matching prospects.
2. For each prospect that scores above the ICP threshold, NORA spawns a deep-research job (capped at $0.30 per account). The dossier lands as a structured AccountBrief with pain points, recent funding, tech stack, and conversation starters.
3. The Email Engine drafts a personalised email per prospect using the right template from the library (ETIA picks it based on persona
   • funnel-stage match), grounded against the AccountBrief so there are no hallucinated claims.
4. Brand Lock validates every draft against the brand voice + tone rules before any email leaves the building. Drafts that fail the validator queue for operator review instead of sending.
5. Governance auto-pauses any send that would exceed the $200/day cap. The operator gets a one-tap "lift the cap" approval flow if they want to push through.
6. Topology shows the entire campaign as one cluster — NORA at the head, the email composer + Brand Lock agents downstream, the reply-classifier and follow-up cadencer queued to fire on inbound responses. The operator watches the cluster's health in real time.
7. Smriti logs every account interaction into the lead's persistent memory. When the same lead replies three weeks later, every agent that touches them reads what was tried, what worked, and what didn't — without the operator having to brief them.
8. Karmic scores every send: which templates got replies, which prospects closed, which segments lifted. Templates that win get promoted in the library; templates that flop get demoted.

By 9:18 am, the operator is back to their actual job. The fleet runs the campaign for the next eight days. The operator drops into MIRA twice a day to approve flagged sends, lift caps, or steer the next move — but they're not babysitting the pipeline.

This same shape — orchestrator chat → applied agents → tools → shared memory → outcome feedback → governance — runs every other workflow on the platform. The marketing team is just the most-visible example.

The rest of this document is the architecture that makes those eight steps work without an operator manually wiring them together.

4. Agentic Substrate — the trust + memory foundation every agent inherits

Most AI platforms force every developer to rebuild memory, governance, audit, and observability for each agent they ship. The Agentic Substrate is what makes Nagent different: it is the missing infrastructure layer in modern AI systems, and every deployed agent inherits its primitives automatically — no manual wiring, no per-agent reimplementation.

The substrate provides four organisation-wide primitives:

• Smriti — persistent cross-agent context fabric
• Karmic — outcome-linked reinforcement and agent evolution
• Agent Control Plane — governance + approvals + intervention
• Audit infrastructure — enterprise trust + compliance evidence

Stage-gated multi-agent orchestration sits on top of these primitives. An agent built today on the substrate has the same memory + governance properties as an agent shipped to production a year ago — because the substrate is the contract, not the agent code.

Smriti — the memory fabric

Smriti is the persistent, per-entity memory layer. Every agent, every lead, every account, every deal, every operator, and every conversation has its own Smriti record — a structured .md-style document that grows as the entity accumulates history.

Key properties:

• Cross-thread continuity. An agent that handled a lead three weeks ago in a different thread can read what was said, what was tried, and what was learned, from any other agent operating on the same lead.
• Cross-agent shared memory. The Decision Engine, the Email Composer, and the Pre-Meeting Prep agent all read from and write to the same Smriti document. They don't have to round-trip through the operator to share context.
• Structured sections. Each Smriti record has predictable sections (background, last interactions, open questions, known constraints, decision history, outcomes) so a new agent reading the document for the first time can find what it needs in O(1).
• Continuous synthesis. Background cron jobs run synthesis passes that compress raw event history into higher-level patterns — so the document stays readable even after a year of accumulated activity.

Smriti is the answer to "why is your agent any better than ChatGPT?" — it is the layer that lets agents remember, and that is the layer nobody else ships out of the box.

Karmic — the feedback binding

Karmic is the outcome-attribution and feedback loop. Every action an agent takes (every email sent, every deal moved, every prompt picked, every variant generated) is logged into an action log that Karmic queries against business outcomes:

• Drafts that get replies → the templates that generated them get promoted.
• Agents whose decisions lead to closed deals get higher trust scores.
• Prompts that produce wins get suggested for re-use.
• Agents that drift (action quality drops below threshold) get auto-demoted on the autonomy ladder until they earn their level back.

The crucial property is that Karmic operates without a human in the loop. The signal is the outcome (reply, meeting booked, deal closed, revenue attributed), and the loop closes through the agent layer automatically. Operators see a "trust score" per agent and can intervene if they disagree, but they don't have to babysit the loop.

   Agent acts        Outcome lands       Karmic attributes
   ──────────        ───────────────     ─────────────────
        │                  │                     │
        ▼                  ▼                     ▼
   ┌─────────┐       ┌──────────┐         ┌──────────────┐
   │  email  │       │  reply   │         │ +  template  │
   │  sent   │──────▶│  booked  │────────▶│    score     │
   │  deal   │       │  closed  │         │ +  agent     │
   │  moved  │       │  no-op   │         │    trust     │
   │  ...    │       │  ...     │         │ -  drift?    │
   └─────────┘       └──────────┘         └──────┬───────┘
   AgentActionLog    Lead / Deal /                │
   (every step)      Engagement events            │
                                                   ▼
                                       ┌──────────────────────┐
                                       │  promote winning     │
                                       │  templates + prompts │
                                       │  demote drifters     │
                                       │  on autonomy ladder  │
                                       │  surface trust score │
                                       │  to operator         │
                                       └──────────────────────┘

Governance — autonomy you can trust

Every agent has an autonomy level from L0 to L4:

Beyond the per-agent level, governance supports:

• Per-action overrides. An agent at L4 can still be flagged "this specific action requires approval even at L4" — e.g. "any outbound to a C-level contact" or "any spend above $1k".
• Kill switch. One operator click pauses an agent, an agent class, or the entire fleet, mid-flight. Pending actions queue, in-flight actions complete and don't trigger downstream.
• Approval engine. Multi-party approval workflows for sensitive actions, with audit trail.
• Action overrides per agent. Operator can tighten or loosen individual agent-action combinations from the governance console.

This is the layer that makes Nagent buyable for regulated industries and for finance-team approval. Agents you can pause, demote, and audit.

   Agent run requests action
              │
              ▼
   ┌────────────────────────┐         no
   │  Action gated at L?    │─────────────▶ ┌──────────┐
   │  (per-action override  │                │ Execute  │
   │   takes priority over  │                │ → log to │
   │   per-agent level)     │                │ AuditLog │
   └──────────┬─────────────┘                └──────────┘
              │ yes
              ▼
   ┌────────────────────────┐
   │  Budget cap exceeded?  │── yes ─▶ pause agent, queue action
   └──────────┬─────────────┘
              │ no
              ▼
   ┌────────────────────────┐
   │   Approval engine      │
   │   • 1-party or N-party │
   │   • notifies approver  │
   │   • times out → reject │
   └──────────┬─────────────┘
              │
        ┌─────┴─────┐
        ▼           ▼
    approved      rejected
        │           │
        ▼           ▼
   execute +     log + emit
   audit        AISuggestion
                for retry

The operator can also flip the kill switch at any level (one agent, an agent class, or the entire fleet). The runtime drains in-flight runs cleanly, queues pending work, and stops dispatching new triggers until the operator lifts the kill.

Audit infrastructure

Three append-only collections back the substrate:

• AuditLog — every write operation across the platform, 365-day retention, immutable.
• AgentActionLog — every agent run with resolution and error context, 90-day retention.
• ExecutionContext — snapshots of context evaluation passes used by the planning layer.

Together they form the evidentiary substrate that compliance teams need to certify the platform.

5. Agent Studio — the environment for designing autonomous AI workers and multi-agent systems

Agent Studio is the design surface for both non-technical operators and engineering teams. The same AgentSpec contract underpins everything authored here — meaning agents created in the no-code builder are first-class with agents written in code, and both inherit the substrate's memory, governance, observability, and runtime orchestration automatically.

Core components:

• No-code form-based builder — guided creation for operators who don't want a chat or an IDE
• Drag-and-drop orchestration canvas — wire agents into multi-agent workflows visually
• Helix — chat-first synthesis from a prose description
• BuildCraft — TypeScript + Python SDK with Git-native workflow
• AgentSpec — the universal contract all paths converge on

The inheritance is the point. An agent designed here automatically inherits:

• Memory — its own Smriti document, plus shared memory with every other agent that touches the same entity
• Governance — autonomy ladder, kill switch, per-action overrides, approval engine
• Observability — runs land in AgentActionLog; actions hit AuditLog; AI suggestions land in the Decisions Ledger
• Runtime orchestration — events, cron, manual triggers; debate participation; topology placement

The operator does not configure these. They are there because the substrate is there.

Agent Studio is part of the paid Nagent platform. Sign in to the control plane to access the no-code builder, Helix synthesiser, orchestration canvas, and BuildCraft SDK.

Agent Studio is the umbrella surface for building agents on Nagent. Two interoperating paths (Helix for chat-first, BuildCraft for pro-code) sit on top of the same AgentSpec contract. Both can compose multi-agent workflow systems — agents wired into orchestration graphs that span multi-model, multi-modal, multi-tool execution under a single governance + memory substrate.

Multi-model means an operator can route different reasoning steps to different foundation models in the same workflow: a Sonnet narrative agent hands off to a Haiku fast-classifier; a vision step uses GPT-4o; a long-context retrieval step uses Sonnet. The model registry picks the right model per step and the runtime handles the swap.

Multi-modal means the workflow accepts text, voice (Whisper transcription baked into the platform), structured data, document uploads (PDFs, slides, transcripts, contracts), and — on the roadmap — video (Tavus / Anam avatars) and ambient audio. Every modality flows through the same Smriti memory layer.

Multi-tool means agents can call from 800+ Composio integrations plus Nagent's native tool layer (Anthropic, OpenAI, Cal.id, ContactOut, Exa, Resend, Razorpay, Cloudinary, MongoDB, Composio, NextAuth, …) through the typed action registry. Every tool an agent uses is validated at design time and audited at runtime.

Helix — chat-first agent builder

Helix is the natural-language path to a working agent. The operator types a sentence ("Create an agent that drafts a daily standup digest from yesterday's pull requests and posts it to Slack at 9am"). Helix synthesises:

• A complete AgentSpec (name, system prompt, autonomy level, risk level, action permissions, triggers)
• Picks the correct model from the model registry based on the task
• Selects tools from the registered action registry — never invents tools that don't exist
• Wires triggers (event names or cron expressions) validated against the canonical event registry
• Suggests skills from the existing skill catalogue

The output ships into the workbench where the operator can edit any field. Behind the synthesizer is a deterministic auto-fix pass that catches and repairs the well-known mechanical invariants (cron field counts, unknown event names, out-of-range autonomy values), so even when the LLM produces an imperfect draft, the persisted spec is always shippable.

Helix also composes multi-agent workflows end-to-end: type "build a workflow that watches my inbox for partnership requests, researches the company, drafts an internal Slack summary for me, and files the lead into the CRM" and Helix proposes the agent graph (watcher → researcher → composer → CRM writer) with the model + tool picks for each step. The operator approves the graph in one screen.

BuildCraft — coding agent for agentic applications

BuildCraft is a coding agent custom-built for agentic applications. Unlike a generic AI IDE, BuildCraft understands the AgentSpec contract, the action registry, the governance primitives, and the runtime — so the code it generates lands on Nagent's substrate ready-to-run, not as orphan snippets a human engineer has to wire up.

It is designed to take a text prompt and produce an entire production-grade application — backend, agent definitions, tool wiring, governance config, deployment manifests — that runs on the substrate.

BuildCraft ships with 9 modules, each responsible for one slice of the application stack:

1. Spec module — synthesises and validates AgentSpec definitions
2. Tools module — wires the action registry, including custom tool authoring and auto-registration
3. Skills module — composes reusable markdown prompt modules
4. Triggers module — event registry, cron expressions, manual invocation paths
5. Data + RAG module — knowledge ingestion, hybrid retrieval, per-document RBAC wiring
6. Governance module — autonomy level, risk level, per-action overrides, approval-engine integration
7. Observability module — AuditLog hooks, Karmic outcome attribution, Decisions Ledger writes
8. UI module — operator surfaces (admin panels, deal rooms, workflow consoles)
9. Deployment module — Cloud Run / VPC / Private Cloud configuration with CI scaffolding

The two paths interoperate: an agent can be drafted in Helix and forked into BuildCraft for advanced custom logic (or for adding new modules), or written in BuildCraft and re-edited via Helix later. Same AgentSpec shape, same substrate, same governance properties.

AgentSpec — the universal contract

Every agent in Nagent — built via Helix, BuildCraft, or pre-built in the marketplace — conforms to the same AgentSpec shape. This is what makes the substrate properties (memory, governance, audit) universal: because every agent is the same shape, the platform can guarantee the same trust properties for all of them.

AgentSpec includes: identity (key, name, description), behaviour (system prompt, model, temperature), capabilities (tools, skills, events), governance (autonomy level, risk level, action overrides, guardrails), triggers (event listeners, cron, manual), and budget (per-day cost cap, per-run token cap).

Validator + Auto-fixer

Both paths run through a validator that checks AgentSpec against the registered action keys, event registry, skill catalogue, and autonomy enums. A deterministic auto-fixer repairs known-bad values before they reach the database — agents always land in a runnable state.

Evaluations — sandbox + production evals

Every agent in Agent Studio has a built-in evaluation surface. Two distinct loops operate side-by-side:

• Sandbox evals — operator runs the agent against a curated set of inputs in an isolated environment before promote-to-production. The workbench surfaces the action chain, the model picks, the tool calls, the token + dollar cost, and the resolution status for each test input. No production state is touched.
• Production evals — once the agent is live, the runtime continuously scores agent runs against a gold-set (operator-curated expected outcomes) and against Karmic signals (replies, meetings, closes, downstream wins). Quality drift is detected automatically and the agent is auto-demoted on the autonomy ladder until it earns its level back.

Eval suites can be attached to skills as well as agents: an operator can ship a new skill version, eval it against the suite, and roll back in one click if the new version regresses. The full eval history per agent + per skill is persisted in AgentActionLog and visualised in the workbench's Observability tab.

Models + Tools registries

Two registries underpin every build:

• Model registry — every model Nagent uses (Sonnet 4.6, Haiku 4.5, GPT-4o, Sonnet vision, Whisper for voice, Anam for video, …) is registered with metadata: context window, per-1M token pricing, best use-case ("narrative", "fast classification", "vision", "long context"). Helix and BuildCraft pick from this registry; the runtime records which model was used per run for cost attribution.
• Action registry — every tool an agent can call (read or write) is registered with parameter schemas, per-tool RBAC, audit hooks, and cost estimates. The Composio bridge auto-registers 800+ third-party tools; native integrations and custom tools are registered by code. Agents cannot call tools that aren't in the registry — there is no free-form HTTP escape hatch.

This is what makes the platform safe at scale: every model + tool an agent uses is declared up-front, governed centrally, and audited continuously.

6. The Runtime

Orchestration

Once an agent is deployed, the runtime handles execution. The orchestrator subscribes to events (or fires on cron), evaluates context, assembles the system prompt, invokes the model, executes tool calls through the action registry, writes outcomes back into memory, and emits downstream events.

   trigger        context        prompt         model           tools
   (event/        eval           assembly       invocation      execution
    cron/         ──┐            ──┐            ──┐             ──┐
    manual)        │              │              │               │
       │           ▼              ▼              ▼               ▼
       └──▶ ┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐
            │   pull   │──▶│  base +  │──▶│  Sonnet  │──▶│  Action  │
            │  Smriti  │   │  skills  │   │  Haiku   │   │ registry │
            │  recent  │   │  trimmed │   │  GPT-4o  │   │  audited │
            │  actions │   │  context │   │          │   │   call   │
            └──────────┘   └──────────┘   └──────────┘   └──────────┘
                                                               │
                            ┌──────────────────────────────────┘
                            ▼
                   ┌─────────────────┐         ┌─────────────────┐
                   │  write Smriti   │────────▶│  emit events    │
                   │  update Karmic  │         │  → downstream   │
                   │  log to Audit + │         │    agents fire  │
                   │  AgentActionLog │         │    automatically│
                   └─────────────────┘         └─────────────────┘

Every step is observable: the operator sees the action chain land in Topology in real time, and the same chain replays from the Decisions Ledger after the fact.

Multi-agent Debates

For high-stakes calls — should this $50k email batch go out? should this lead be upgraded to a hot opportunity? should we recommend a discount? — Nagent supports moderated multi-agent debates. Specialist agents (Decision Engine, Cost-Cap, Brand-Voice, Risk Assessor) argue a decision under a moderator before any action fires. The full debate is logged. Round-robin cadence with a hybrid stop condition (consensus or N rounds) and a $20/day per-debate spend cap.

This is one of the unique-to-Nagent moments. Every other platform on the market today ships a single-agent execution model.

                ┌────────────────────────┐
                │   Decision: should X   │
                └────────────┬───────────┘
                             │
                ┌────────────▼───────────┐
                │      MODERATOR         │
                │   (manages turns,      │
                │    enforces caps,      │
                │    declares consensus) │
                └────────────┬───────────┘
                             │
        ┌───────────┬────────┼─────────┬────────────┐
        │           │        │         │            │
   ┌────▼────┐ ┌────▼────┐ ┌─▼──────┐ ┌▼─────────┐  │
   │Decision │ │ Cost-Cap│ │ Brand- │ │   Risk   │  │
   │ Engine  │ │  Agent  │ │ Voice  │ │ Assessor │  │
   │ (Y/N +  │ │ (budget │ │ (tone  │ │ (compliance│ │
   │  basis) │ │  check) │ │  fit)  │ │  signals)│  │
   └─────────┘ └─────────┘ └────────┘ └──────────┘  │
        └──────────────────┬──────────────────┘     │
                  round-robin turns                  │
                  hybrid stop                        │
                  ($20/day cap, max N rounds,        │
                  early consensus)                   │
                             │                       │
                ┌────────────▼───────────┐           │
                │    DECISION + FULL     │───────────┘
                │    DEBATE TRANSCRIPT   │
                │    → AgentActionLog    │
                │    → Decisions Ledger  │
                └────────────────────────┘

Topology / Live Ops cockpit

The Topology view is the real-time cockpit of every agent in the fleet: what each agent is doing right now, what it just decided, where the next handoff is queued, which agents are debating, which are waiting on approval. Operators can pause, demote, isolate, or override any agent from the cockpit without losing the run state.

This is the enterprise-confidence killer when shown to a CTO. Most agentic platforms ship a chat box. Nagent ships the cockpit underneath it.

Trigger system

Agents fire on three trigger types:

• Event — published from anywhere in the platform. The event registry defines the canonical event names so triggers can't drift.
• Cron — validated cron expressions for time-scheduled work.
• Manual — operator invocation from the workbench or the API.

Action registry

Every action an agent can perform is registered in a typed action registry. Helix only suggests tools that exist; BuildCraft compiles against the same registry; the governance layer gates per-action overrides against it.

7. The Application Layer

Marketplace

200+ pre-built agents across 10 top-level categories (sales, marketing, content, ops, support, BFSI, FMCG, fashion, eCommerce, SaaS, …). Operators can deploy any agent into their fleet with a click; the marketplace agent inherits all substrate properties automatically.

Agent Stacks — orchestration graphs

Stacks are multi-agent compositions. Operators wire agents together into a visual orchestration graph (React Flow canvas) — output of one agent feeds the next, with conditional branches, parallel fan-out, and handoffs. Stacks are first-class entities: they have their own Smriti, their own Karmic feedback, their own governance bounds.

Skills

Skills are reusable markdown prompt modules attached to one or more agents. A skill defines when to use it (trigger description) and how to apply it (the prompt instructions), and includes optional allowedTools[] to restrict which actions it can compose. Skills are stored as .md-style records in the database and surfaced in the admin skills catalogue. Operators can create skills from prose, from a PDF upload, or by hand.

8. Ops Layer — multi-agent managers

The Ops Layer is where multi-agent managers coordinate, supervise, and route work across fleets of specialist agents. This is not a chat interface and these are not chatbots — MIRA, NORA, and the Sales Assistant are operational coordinators that handle execution management, workflow routing, task delegation, and escalation across agent fleets.

Think of it as AI middle management for an autonomous workforce: the specialist agents do the work, the Ops Layer decides which agents do what, in what order, with what handoff, and when to escalate to a human operator.

MIRA — the orchestrator chat

MIRA is the super-coordinator. Live on the public site at /agents/mira, MIRA is the operator's front door to the platform. Internally, MIRA orchestrates handoffs between specialist agents (NORA for outbound, the Sales Assistant for inbound, the Content Studio for assets). Externally, MIRA is also the entry chat for prospects evaluating Nagent.

NORA — autonomous outbound prospecting

NORA is the production outbound prospecting agent. 22 tools across DNA / discovery / research / drafting / sending / replies / cadence / pipeline. ICP-driven (operators define the Ideal Customer Profile once; NORA auto-synthesises a Lookalike Profile and runs against it). Cost-capped (daily spend ceiling, per-run token cap). Outcome-attributed (replies, meetings, closes all flow back through Karmic). Operates end-to-end without operator intervention at L4.

Sales Assistant — multi-turn lead nurture

The inbound counterpart. Multi-turn conversation with leads via chat and email, with structured capture (intent, budget, timeline, decision process) that auto-advances the lead through the pipeline. Includes voice input, anti-hallucination validators, and a role-lens prompt extension that frames every output for the recipient's role.

Email engine

A complete email production pipeline:

• Template library with persona / funnel-stage / tone / category metadata — 79 production templates seeded from the GTM design system.
• EmailBuilder that generates and ranks variants for a given context.
• Sequence engine with cadence, AB-variant promotion, reply handlers, breakup logic, frequency caps.
• Send pipeline via Resend, with delivery + reply + click tracking.
• Anti-hallucination validator that grounds every claim against the source-of-truth fields on the Lead and AccountBrief.

Pre-meeting prep cards

For every Cal.id booking on a lead, the pre-meeting prep agent auto-generates a five-minute briefing for the operator: who they're meeting, what's happened in the relationship, the open questions, the likely objections, the suggested next-step. Drops into the operator's calendar invite or email.

Deal Rooms

Shareable per-lead micro-sites. The operator creates one with a click; the prospect gets a private URL they can visit without auth. Includes the proposal, the relevant marketplace agents, the case studies, and a booking link. Every visit and every click is tracked back to the Lead timeline.

Account research

GPT-4o deep dossier per lead's company. Pulls public signals (job postings, tech stack, recent news, recent funding) and synthesises a structured AccountBrief: key competitors, pain points, tech stack, conversation starters, potential objections, buying signals.

9. The Content + Brand Layer

Brand workspaces (multi-tenant)

For agencies, multi-brand enterprises, and partner ecosystems. Each workspace is fully isolated: its own brand book, its own agent governance, its own model preferences, its own audit trail. Operators can switch between workspaces with a click; permissions are scoped per-workspace.

Content Studio

A managed-service team plus a software surface. Operators use the Content Studio to commission and review brand-aligned creative output — articles, videos, ad creative — produced by content agents that share the workspace's brand book. The Brand Voice Analyzer agent grades every output before it's surfaced to the operator.

Brand Lock AI

Public free tool at /brand-lock-ai. Visitor pastes a URL + logo + references; the tool produces a complete brand book (12 engines: brand energy model, narrative cognition, contexts, reasoning layers, competitive differentiation, validation rules, etc.) plus a printable PDF. Doubles as a lead-magnet — the public-facing demo of the brand substrate that paid Brand workspaces use internally.

10. The Observability Layer

AuditLog

Already described in the substrate. Every write op, 365-day retention, immutability enforced at the schema level, not in application code. The evidentiary layer.

AgentActionLog

Every agent run logged with resolution, errorMessage, action chain. Powers the Karmic feedback loop and the operator's per-agent timeline.

Troubleshoot endpoint

Staging + localhost only. Captures every 500-class API error with route, method, payload preview, stack trace. Operator and platform engineer can query recent failures from a single endpoint, gated by a bearer token, with a 7-day TTL. Production hosts refuse the endpoint even with a valid token — diagnostic data never leaks to prod URLs.

Decisions Ledger

Every AI-suggested action (recommend stack, suggest next email, propose autonomy change) is logged against the entity it affects, with the outcome it produced. Operators can replay the chain to understand why a particular decision was made and what it led to.

11. Ingredient Layer — the modular capability surface underneath every execution

The Ingredient Layer is the foundational capability surface that powers every agent execution path. It is not a user-facing surface — operators don't interact with it directly. They interact with the agents above it; the Ingredient Layer is what those agents draw from to reason, retrieve, decide, and act.

Four composable capability families sit at this layer:

AI Models

The full live registry — every foundation model the platform ships against, with context windows, per-1M token pricing, supported modalities, and best-use guidance — is browsable at /resources/models. Today's lineup covers Sonnet 4.6 (narrative reasoning), Haiku 4.5 (fast classification), GPT-4o (vision + general), Sonnet vision, Whisper (voice transcription), and the video-avatar providers (Anam / Tavus). The runtime records which model was used per run for cost attribution.

Multi-model routing means a single workflow can hand off between models step-by-step — narrative Sonnet → fast Haiku → vision GPT-4o → long-context retrieval — without operator wiring. Cost-sensitive workflows see 60–80% measured reductions. Helix + BuildCraft pick from this registry at design time; the registry is the single source of truth for which models the platform supports today.

Private Cloud deployments support bring-your-own-key and can pin specific model versions for reproducibility + compliance.

Tools / MCP / Integrations

The full live catalogue — every Composio integration and native tool the platform ships against, browsable + searchable — lives at /resources/tools-and-integrations.

Every tool an agent can call (read or write) is registered with parameter schemas, RBAC slugs, audit hooks, and cost estimates:

• Composio bridge — auto-registers 800+ third-party tools (Salesforce, HubSpot, Pipedrive, Gmail, Outlook, Slack, Discord, Teams, Snowflake, BigQuery, Airtable, Mailchimp, ActiveCampaign, …)
• Native integrations where deeper control matters — Anthropic, OpenAI, Cal.id, ContactOut, Exa, Storyblok, Razorpay, Cloudinary, NextAuth
• MCP servers — Model Context Protocol bridges to enterprise systems that ship MCP endpoints
• Custom tools — authored in BuildCraft and auto-registered on deploy

Agents cannot call tools that aren't in the registry — there is no free-form HTTP escape hatch. This is what makes governance enforceable at runtime, not just at audit time. The /resources/tools-and-integrations page is the canonical answer to "does Nagent integrate with X?" — operators can search the full catalogue without a sales conversation.

Data + Knowledge (Enterprise RAG)

Three ingestion paths feed the agent-readable knowledge layer:

• Document ingestion — PDFs, slides, contracts, transcripts
• Structured connectors — databases, data warehouses, CRMs
• Live API mirrors — selected systems mirrored on schedule or event

Retrieval is hybrid (vector + keyword + structured filters + re-ranker) with knowledge-graph relations for multi-hop reasoning. Every retrieval is logged to the Decisions Ledger with sources cited. Per-document RBAC is enforced at retrieval time, so source citation in the audit trail reflects who could actually see what.

Skills + composable capabilities

Skills are versioned, reusable prompt modules attached many-to-many to agents. Each skill declares when to use it and how to apply it, with optional allowedTools[] restrictions. Skills can be authored from prose, PDF upload, or by hand. Eval suites attach to skills so a new version ships, evaluates, and rolls back like code.

Cal.id native meeting layer

Calendar booking built into the platform rather than wired as a connector. The Lead → Cal.id booking flow is one click; the booking generates a pre-meeting prep card; the meeting outcome flows back into Smriti automatically.

The Ingredient Layer is the answer to "what does an agent draw from when it runs?" It is modular (any agent can use any ingredient under its RBAC), composable (workflows mix models, tools, knowledge sources per step), and centrally governed (every ingredient is registered, audited, and cost-attributed).

Composio — 800+ integrations

Nagent uses Composio as the broad-coverage integration layer. Any agent can call any of 800+ third-party tools — CRMs (Salesforce, HubSpot, Pipedrive), email (Gmail, Outlook, Resend), chat (Slack, Discord, Teams), data (Snowflake, BigQuery, Airtable), marketing (Mailchimp, ActiveCampaign), and more.

Native integrations

For tools where Nagent needs deeper control than Composio offers, we ship native integrations: Anthropic, OpenAI, Cal.id, ContactOut, Exa, Storyblok, Razorpay, Cloudinary, NextAuth.

Cal.id native meeting layer

Calendar booking is built into the platform rather than wired as a third-party connector. The Lead → Cal.id booking flow is one click; the booking generates a pre-meeting prep card; the meeting outcome flows back into the Lead's Smriti automatically.

12. Education + Adoption Layer

ETIA — Email Template Intelligence Agent

Indexes every template in the library against persona / funnel-stage / tone / outcome history. When an operator (or another agent) needs a template for a given context, ETIA matches, resolves, and adapts the best candidate. Produces an explanation for the pick so operators understand why a particular template was chosen.

Education layer (HelpHint / AIHelp / RelatedLinks)

Inline contextual help on every admin surface. HelpHint shows a "why does this exist?" tooltip on any feature; AIHelp answers operator questions about the platform from the platform's own documentation; RelatedLinks surfaces complementary features the operator hasn't discovered yet. Activity-driven — the more the operator works in a surface, the more advanced the suggestions get.

13. Enterprise readiness — what the platform is designed for

These are the operational guarantees and instrumentation points relevant to procurement, compliance, and platform-engineering evaluators. The numbers below are conservative — production deployments operate inside them comfortably.

Scalability

• Fleet size: Control Plane + Topology are designed to surface hundreds to low-thousands of concurrently-deployed agents per workspace. The materialised view keeps the operator UI responsive independent of fleet size.
• Concurrent runs: agent runs execute on an event-driven runtime; scale-out is horizontal under Cloud Run autoscaling. There is no single-threaded bottleneck on the hot path.
• Cost scaling: every model call is attributed per-run to per-agent cost lines, so cost grows in proportion to actual workload, not in proportion to deployed agent count.

Multi-tenant isolation

• Brand workspaces are the isolation primitive: own brand book, own agent governance, own model preferences, own audit trail.
• Private Cloud deployment is single-tenant: dedicated control plane, dedicated database, dedicated inference gateway, all inside the customer's VPC (AWS / GCP / Azure) or, on request, on-prem.
• Per-workspace RBAC is enforced server-side on every admin API route — the front-end is not the security boundary.

Security

• VPC-isolated inference, encryption at rest + in transit
• Customer-managed encryption keys (CMK) on Private Cloud
• VPC peering / PrivateLink for upstream connectors
• SOC-2 + ISO-27001 control alignment; HIPAA-aligned access controls
• Bring-your-own-key for foundation models on Private Cloud
• No free-form HTTP escape: agents can only call tools registered in the action registry, so security review focuses on the registry, not on every agent's prompt

Observability + audit

• AuditLog — every write op, 365-day immutable retention
• AgentActionLog — every agent run with resolution + error context, 90-day retention
• Decisions Ledger — every AI-suggested action with its outcome, replayable
• Per-run cost attribution — model, tokens, dollar cost, all logged

Rollback + reversibility

• Skill versions one-click rollback to the last-passing version
• Agent autonomy demotion from L4 to L0 in one click
• Kill switch: one-click pause of agent, agent class, or full fleet, mid-flight; pending actions queue, in-flight actions complete
• Per-version eval suites — prompt changes ship like code changes

Approval chains

• Per-action overrides on top of the autonomy level
• Multi-party approval engine for sensitive workflows
• Budget caps with auto-pause on exhaustion
• JIT access for time-bound privilege grants
• Sensitive-role MFA on operator login for governance surfaces

Latency + reliability

• Human override response time: kill switch takes effect within the runtime's next scheduling tick — sub-second for event-driven agents, next cron firing for scheduled ones.
• Reliability tier: production runs on Google Cloud Run with autoscaling; Private Cloud deployments include a customer-agreed SLA.
• Latency: end-to-end latency is dominated by the foundation-model call. Platform overhead per run — context assembly + action dispatch — is typically under 300 ms.

Token + cost governance

• Per-run token cap auto-pauses runs that exceed it
• Per-day dollar cap auto-pauses agents that exceed it
• Per-debate spend cap (default $20/day) on multi-agent debates
• Per-research cap ($0.30 typical) on deep-research jobs
• Multi-model routing lets cost-sensitive workflows route easy steps to Haiku and reserve Sonnet for hard steps — measured cost reductions of 60–80% on workflows that adopt this pattern

Proof points from production

• 200+ marketplace agents shipping today, inheriting full substrate
• 800+ third-party tools auto-registered via the Composio bridge
• 365-day immutable AuditLog retention with schema-level enforcement
• L0–L4 autonomy ladder with automatic demotion on quality drift

14. Agentic AI Lab — how Nagent assembles everything for an enterprise

The Agentic AI Lab is the bespoke engagement where Nagent's senior team takes the layers in this document and assembles them into a working autonomous-operations system for one specific enterprise. It is the answer to "we want to become AI-native — what does that actually look like for us?"

A Lab engagement spans three phases:

1. Diagnose. A structured 2-week assessment of the operational reality — workflow inventory, data + integration topology, SOP maturity, current AI usage, blockers — capped with a written architectural recommendation and a phased rollout plan grounded in the Agentic AI Readiness Index (next section).
2. Build. Nagent's engineering team ships the recommended multi-agent system on the substrate — agents designed in Agent Studio (or written in BuildCraft for advanced cases), wired into stacks, with the right tools / models / data integrations from the Ingredient Layer, governed through the Agent Control Plane.
3. Operate. Cut-over to the customer's operators with a 2–4 week supervised live-run window. Topology + Decisions Ledger + Karmic are visible to both sides during this period; ownership transfers when the customer's team is confident.

What makes the Lab distinct from a consulting engagement is the substrate dividend: every agent the Lab ships inherits Smriti + Karmic + governance + audit automatically. Six months after the engagement closes, the customer's agents are still learning from outcomes (Karmic), still accumulating organisational memory (Smriti), and still operating inside the governance bounds set during the build. The Lab does not leave behind a static deliverable; it leaves behind a living agentic operating layer that compounds.

Typical Lab outputs:

• A multi-agent stack tailored to one or two high-value workflows
• A working Topology + Control Plane deployment the customer's ops team uses daily
• A governance + RBAC configuration aligned with the customer's regulatory + audit requirements
• A Karmic feedback wiring so business outcomes flow back into agent trust scores automatically
• A capability-transfer programme so the customer's own teams can extend, edit, and ship new agents themselves after the engagement

The Lab is the way enterprises in regulated industries — BFSI, healthcare, pharma, insurance, public sector — get to AI-native without rebuilding the substrate themselves.

15. Agentic AI Readiness Index — comprehensive assessment + benchmarking

The Agentic AI Readiness Index is Nagent's public assessment + benchmark of how ready an organisation is to deploy autonomous AI workflows. It is the on-ramp to a Lab engagement, and it is also a standalone tool any operator can use to evaluate their own programme.

Five dimensions are scored:

1. Workflow maturity — are the workflows structured enough to automate? Are SOPs documented? Are exceptions known?
2. Data + integration readiness — what data is accessible? What systems have APIs? Where are the manual handoffs?
3. Governance + risk posture — what approvals exist? What's the audit requirement? What's the regulatory exposure?
4. Operator readiness — is there a team that can supervise an AI fleet? Do they have observability tooling? Are KPIs measurable?
5. Organisational change capacity — can the organisation absorb workflow shifts? Is leadership aligned?

Each dimension is scored 0–100, and the composite maps to one of four readiness tiers (Foundational · Operational · Optimised · Frontier).

The Index goes one step further than most assessments by benchmarking your readiness against peers along three axes:

• Geography — North America · EU · UK · APAC · MENA · LATAM
• Industry — BFSI · healthcare · pharma · insurance · retail · manufacturing · telecom · SaaS · public sector · …
• Function — sales · marketing · ops · support · research · finance · compliance · HR

So a Mumbai-based insurance ops leader doesn't just see "62/100 — Operational tier". They see "62/100 — your peers in insurance ops in APAC average 51; the top quartile is 78; the dimensions you're behind on are data integration and operator readiness." The benchmark contextualises the score and points at the next concrete move.

Methodology: the Index is updated quarterly from a combination of public deployment data, Nagent customer telemetry (anonymised + aggregated), and structured assessments from the diagnosis phase of Lab engagements. Index reports are exported as branded PDFs that operators can share with leadership.

16. The business model — how Nagent packages this

Every capability in this document is a building block, but customers don't buy building blocks — they buy outcomes. Here is how the stack is packaged commercially:

The substrate (Smriti + Karmic + Governance + Audit) is a single codebase, shipped with every tier. What changes between tiers is the deployment model (shared multi-tenant → single-tenant VPC → on-prem), the engagement model (DIY → marketplace + studio → bespoke lab), and the included applied agents.

This packaging makes the same platform legible to a startup founder buying Studio + a few marketplace agents AND to a Fortune-500 CIO buying the Lab engagement on Private Cloud with the full Governance layer — without forking the codebase.

17. Why this is hard to replicate — the moat

It is easy to ship a chat box on top of a foundation model. It is hard to ship the substrate that makes agents trustworthy at enterprise scale. The moat is in the layers underneath the chat:

1. Shared memory substrate (Smriti). Every entity in the system has a persistent, structured memory document that all agents read and write. Not opt-in, not bolted on — every agent inherits it automatically. Building this properly requires a unified ingestion path, a continuous synthesis pass to keep memory readable over months, and per-entity RBAC at the retrieval layer. Most platforms ship vector-only RAG and call it memory.

2. Outcome-attribution feedback (Karmic). Every action is linked to a downstream business outcome (reply, meeting, close, revenue), and the loop closes through the agent layer without a human in the middle. Building this requires both the action log AND the outcome attribution AND the per-agent trust score AND the autonomy demotion mechanism — all designed together. Most platforms log actions and stop there.

3. Governance + autonomy as substrate, not feature. L0–L4 autonomy ladder, per-action overrides, kill switch, multi-party approvals, immutable audit — all enforced at the substrate level, not added per-agent. The operator can demote any agent without redeploying. Building this requires the governance bounds to be primitive types in the AgentSpec, not metadata flags.

4. Multi-agent orchestration runtime. Moderated multi-agent debates, agent stacks, conditional graphs, parallel fan-out, handoffs — first-class primitives, not chained API calls. Building this requires a typed action registry, a debate-moderator skill, a hybrid stop condition, per-debate spend caps, and the observability to inspect a debate as it happens. Most platforms ship single-agent execution.

5. Operator visibility (Control Plane + Topology). Real-time SSE-driven cockpit of the entire fleet, plus a living-systems Topology view that clusters agents into systems and shows cognitive gravity at a glance. Building this requires a materialised view (so the UI renders at fleet scale), a Smriti+Karmic aggregator at the cluster level, and a UI operators actually want to live in. Most platforms ship a list view.

6. Unified AgentSpec contract. Every agent — chat-built (Helix), code-built (BuildCraft), pre-built marketplace — conforms to the same shape. This is what makes the substrate properties universal. Most platforms have separate shapes for no-code agents and SDK agents, and the substrate properties (memory, governance, audit) apply unevenly.

These six layers compose. Building any one of them in isolation is a project; building all six so they interlock is the work of a year or more. That interlock is the moat.

18. Where this is going

Nagent's long-term frame is the operational consciousness layer for AI-native organisations. Today the platform is multimodal in text and structured data; the next phase extends to voice (operator and agent voice cloning via Anam), video (avatars via Tavus / Anam), and ambient audio. The aspiration is a fully multimodal Agent Communication Protocol (ACP) where agents communicate across modalities the way humans do — voice notes, video updates, ambient listening, structured data, all routed through the same Smriti + Karmic substrate.

When that ships, Nagent stops being an "AI agent platform" and becomes the operating system for an autonomous organisation — the layer underneath every other tool, the substrate every agent inherits, the memory every operator shares.

19. Appendix A — Glossary

This document is the technical narrative companion to the public site at nagent.ai and the operator console at nagent.ai/admin. For deeper technical conversations or a working session with the founding team, book a 30-min slot.