The agnticr Book

Every business runs on recurring, semi-structured work that nobody loves: chasing replies, coordinating people, monitoring inboxes, compiling reports, updating records, following up with customers and suppliers. It isn't glamorous, but it is the connective tissue of a company — and today you have three bad options for it:

1. 1.Do it manually. Expensive, slow, error-prone, and soul-crushing for the person stuck with it.
2. 2.Automate it with rigid workflow tools (Zapier, Make, n8n). It works right up until reality deviates from the flowchart — the supplier replies with a question instead of a confirmation, the spreadsheet grows a new column, the API returns something unexpected. The flowchart doesn't bend; it breaks. Often silently.
3. 3.Paste it into a chatbot. Wonderful for a one-off answer. Useless for work that has to happen, reliably, every week, with accountability.

Meanwhile, AI assistants — coding copilots, desktop agents, personal assistants — made one person dramatically faster at their desk. That's their ceiling: they are personal tools, not employees. Close the laptop and the work stops. Nobody approves anything. Nothing is remembered. Nothing is owed to anyone.

Agnticr exists for the other 95% of business work: the work that must get done, not just assisted.

The one-liner: Coding copilots help you work faster. Agnticr puts work on autopilot — real business jobs that run for hours, days, or weeks, pause to ask a human over WhatsApp when judgment is needed, and learn from every run.

The founding insight behind Agnticr is that businesses don't buy tools for this kind of work — they hire people. And what makes a good employee valuable is not raw intelligence. It's a bundle of qualities no chatbot has:

• They own outcomes, not steps. You say “handle the weekly member outreach,” not “click these fourteen buttons in order.”
• They know when to ask. A good employee doesn't email 500 customers without checking; they also don't interrupt you for every keystroke.
• They keep working when you're not watching. The work doesn't depend on your laptop being open.
• They get better. The tenth week beats the first, because they remember what worked, what didn't, and what you told them.
• They're accountable. You can see what they did, why they did it, and what it cost.

Agnticr is the product of taking that list literally and building each quality into software:

That's the whole book in one table. Everything else is the how.

An honest product knows what it is not. Agnticr is routinely compared to three categories, and the differences are the point.

Versus copilots and desktop agents

We love these tools; many of us use them daily. They make individuals faster. But four things change when the work belongs to a business instead of a person:

1. 1.The work can't live on a laptop. A desktop agent's schedule runs when your machine runs. An Agnticr job runs in the cloud on durable workflow infrastructure — it survives reboots, deployments, and vacations, and can wait three days mid-job for a customer's reply without losing its place.
2. 2.Approval needs to be a protocol, not a prompt. Desktop agents keep you in the loop while you're at the desk. Agnticr's gates are declared in the plan, enforced by the engine, and answerable from WhatsApp, web, or voice by whoever owns the decision — and the approval becomes part of the quality record the job is judged against.
3. 3.A business needs the tenth run to beat the first. Desktop tasks start fresh each time. Agnticr jobs end every run with a structured review that grades what helped and what hurt, retires stale guidance, and evolves the plan itself.
4. 4.Personal-scope access is the wrong trust model for a company. A desktop agent acts with your logged-in access on your machine. Agnticr holds credentials server-side, exposes only allowlisted operations to the agents, scopes everything per tenant and project, and itemizes what every run cost.

Versus workflow automation

Workflow tools (Zapier, Make, n8n, Power Automate) automate flowcharts. Agnticr automates outcomes. A zap does exactly what you drew — which is exactly the problem, because real work doesn't follow the drawing. When reality deviates, Agnticr's agents adapt mid-run: retry differently, escalate to a stronger model, propose plan changes with evidence, or pause and ask a human. And where a workflow tool leaves you a growing museum of brittle automations only their author understands, Agnticr's plans review and improve themselves after every run.

When should you still use them? Deterministic, high-volume data plumbing — sync these rows, forward that webhook. Those tools are excellent at it, and Agnticr coexists happily: agents can call your existing automations through APIs like any other system. The dividing line is simple: if the work needs judgment, conversation, or approval, it's a job, not a flowchart.

Versus agent-builder platforms

These give you a workbench to construct your own agents — you write the prompts, design the orchestration, wire the guardrails, and keep it all working as models change. Great product, for teams whose business is building agents. Agnticr ships the finished department: a planner, named specialists, approval gates, self-improving plans, cost tracking, and tenant-grade governance — pre-built, integrated, and getting better on its own. Most businesses shouldn't be in the agent-construction business.

Why a team of named agents instead of one big model? For the same reason companies have departments: specialization makes each unit better, and a coordinator keeps you from having to know who does what. You talk to one agent; the org chart is her problem. Named agents also make the product legible — “Joel sent 34 emails” reads like a status report from a colleague, not a log line from a system.

You don't get “an AI.” You get a staffed department, orchestrated by Agnes:

One chat, one phone number, one team. Behind the scenes this is a governed org chart: a root orchestrator delegates to specialists, each with its own tools, guardrails, and — where it matters — its own model tier. Specialists that handle heavy data (Davie fetching records, Cindy reading web pages) run their bulk work in context-isolated sub-agents that return only conclusions, so a thousand database rows never clog the conversation. That isolation is a cost feature and a quality feature: the orchestrator stays focused on your goal, not on raw payloads.

Why multiple channels? Because the person who needs to approve an email at 3 PM is rarely sitting at a dashboard at 3 PM. Work stalls at exactly the speed of its slowest approval — so Agnticr goes to where the approver already is.

• Web chat is the home base: full sessions, streaming reasoning, artifacts, dashboards, and the complete job workbench.
• WhatsApp and SMS carry the decisions that keep work moving. A job pauses at a gate, your phone buzzes, you reply “approve, but mention the June event” from the school pickup line — and the job adapts and continues. Replies are interpreted semantically, in your language, not matched against rigid keywords (Chapter 8).
• Voice — Linda answers and speaks on real phone calls, for the situations where a conversation is faster than a thread. She handles interruptions naturally — talk over her and she stops — and anything consequential (triggering a job, resolving an approval) requires her to restate the exact action and get spoken confirmation first.
• Email — inbound mail can wake the session that was waiting for it and resume the work mid-thread.

Sessions themselves are persistent, resumable conversations — not ephemeral chat windows. A session can carry an objective, a working plan, and scheduled follow-ups: “check back on this Thursday” becomes a durable timer that wakes the session and resumes the agent — with or without you present — rather than something you have to remember.

The conversation layer also heals itself. When a model call fails mid-turn — a transient provider error, a dead end — a recovery layer classifies the failure and responds proportionately: quietly retry and resume where the stream left off (never replaying a message that already went out), bring in a supervisor model to steer past a dead end, or surface the problem honestly. You see a brief recovery notice, not a broken conversation.

A team that remembers you

Two mechanisms make the team feel less like a fresh hire every morning:

• Agent memory. The platform maintains a tenant-wide, semantically indexed store of durable facts about how your team works — “always use Swedish names in this project,” “validate emails before sending.” Facts are extracted automatically when sessions close (Agnes can also be told to remember something mid-conversation), recalled by relevance into every agent turn, deduplicated and aged out over time, and fully visible to operators — who can pin the ones that must always apply, or delete the ones that shouldn't. Learn once, recall everywhere.
• Project guidelines. Standing instructions written once per project — your house rules — injected as system-level guidance into every agent call in that project. No cost when empty, no repetition when set.

Why plans at all? Because “just let the AI figure it out each time” gives you a different employee every Monday. A plan makes the work inspectable before it runs, repeatable across runs, and improvable between runs. You can read it, approve it, and hold the execution accountable to it.

Why milestones instead of steps? Early versions of the engine (and most competing systems) modeled plans as lattices of micro-steps. It fails for a deep reason: rigid step sequences fight the model instead of using it. Modern models are good at decomposing work in the moment — what they need is a clear outcome, its success criteria, and its constraints. So an Agnticr plan is a set of milestones: outcome-grained units an agent owns end-to-end, each with declared dependencies, success criteria, deliverables, human gates, and side-effect declarations. The plan describes the what; the executing agent owns the how, with its reasoning intact.

How it works, briefly:

1. 1.You describe the job in plain language — or ask Michael in chat, who interviews you, recommends connectors, and drafts it for you.
2. 2.A planner seat running a strong model at high reasoning effort generates a plan, validated against a strict schema.
3. 3.The plan lands as an immutable, versioned revision with full provenance. You review it in a read-only workbench — plans are authored by the model and reviewed by humans, never hand-edited into inconsistency.
4. 4.Dependencies form a flat graph across milestones, so independent work can run in parallel naturally.
5. 5.The planner even declares the reasoning effort each milestone needs — flagging analysis-heavy milestones so the engine can escalate them to a stronger model at runtime (Chapter 21).

The plan generation is itself workspace-aware: the planner receives an inventory of the job's existing files, collections, and knowledge base, so run five's plan extends what runs one through four built instead of reinventing it.

One more authoring detail with outsized value: mentions and placeholders. Plain language is wonderful until “use email to send the report” has to mean one specific mailbox. Typing @ in a job definition offers your actual resources — your Gmail connection, your leads collection, your mail agent — and named placeholders stand for configured or runtime-supplied values. The tokens resolve canonically before planning and execution, so chat, planner, and executor all share one unambiguous interpretation of what you meant — no guessing which of your three mail systems “email” refers to.

Why durable execution? Because business work pauses. A job that emails a supplier may wait three days for the reply. A job that needs approval may wait until the owner lands from a flight. If your execution engine can't survive a deployment, a crash, or a long human pause without losing its place — or worse, double-sending an email — it cannot be trusted with real work.

Agnticr jobs run on Temporal, the same class of durable-workflow technology that powers banks' transaction systems. What that buys you, in plain language:

• Crash-proof progress. If a worker restarts mid-job, the workflow replays its history and continues exactly where it was. No cron-and-pray.
• Waits measured in days, for free. A gate or an external reply can take as long as it takes; the job sleeps durably and resumes the moment the answer arrives.
• No double side effects. Every backend write carries an idempotency key; retried operations don't send the email twice.
• Bounded by construction. A hard ceiling caps how many agent rounds any milestone can consume across every path — fresh runs, retries, gate reruns, resume-after-pause — so a milestone can never loop forever. Retries are semantic: the workflow decides whether to retry and threads the previous failure summary into the next attempt's brief, so the model learns from its own miss instead of blindly repeating it.
• Parallel where the plan allows. Milestones whose dependencies are satisfied can run concurrently, so independent workstreams inside one job don't queue behind each other.
• An honest completion contract. A milestone is done only when the agent explicitly submits completion with its declared deliverables and a per-criterion assessment. A run that produced none of its deliverables is a failed attempt — never a silent success.

Each milestone executes as its own agent session with a rich brief: the milestone's outcome and criteria, results from dependency milestones, accumulated learnings, operator guidance, and the job's working memory. Different execution seats (milestone execution, review, adjudication, approval interpretation…) route to different models suited to their stakes (Chapter 21).

Why gates? Because the single biggest blocker to delegating work to AI is not capability — it's anxiety. “Would you let AI email your customers?” You would if it asked first. Gates convert delegation-with-anxiety into delegation-with-control, and that unlocks everything else.

Agnticr's human-in-the-loop system is a protocol, not a chat hack:

• Declared in the plan. Milestones declare before-gates (“check with me before starting this”), after-gates (“show me the result before it counts”), and side-effect approvals (“this milestone sends email — pause before anything irreversible”). Consequences are visible at plan-review time, before a single action runs.
• Enforced by the engine. A gate creates a pending decision request and the workflow durably waits. Not “the model remembered to ask” — the engine cannot proceed without the answer.
• Answerable anywhere. Web, WhatsApp, SMS. Natural-language replies — paraphrases, emoji, Swedish — are interpreted by a dedicated messaging agent running a judgment-grade model, with a confidence-based confirmation step so a vague reply gets a quick “just to confirm?” rather than a wrong guess. A hard invariant guarantees that only a genuine approval intent can ever approve: any other interpretation forces a non-approval.
• Semantically meaningful answers. Rejecting a before-gate stops the irreversible action. Rejecting an after-gate means “please revise” — the same milestone session resumes and adapts, within its rerun budget. “Approve, but change the subject line” is a first-class response, not an error.
• Tunable autonomy. Every job has an autonomy level — from always ask to never ask — that governs how eagerly the engine pauses, including an optional tool-risk gate that pauses on destructive tool calls regardless of the plan.

And crucially: the approval itself becomes evidence. The final quality judge sees what you approved, so jobs are graded fairly against the decisions you made.

Why is this the differentiating chapter? Because everything else in this book — plans, durability, gates — has some analog somewhere. This mostly doesn't. Run the same job ten times on a typical automation platform and run ten is identical to run one. Run it ten times on Agnticr and run ten is cheaper and better, because the system studies itself. A job compounds like a good employee does.

Three mechanisms work together:

1. An independent verdict. When a run finishes, an adjudicator — a separate judgment-grade model seat — delivers the authoritative pass/fail verdict against the job's stated objective. It is deliberately independent of the agents that did the work: the student doesn't grade its own exam. If the adjudicator is unavailable, the run lands in a needs-review state rather than guessing — an honest “I don't know” beats a confident fiction.

2. Graded, structured learnings. A reviewer then writes a structured retrospective: what worked very well, what did not, which tools succeeded, and which human answers are reusable. This is not a diary — it's a curated memory with quality control:

• Every prior learning is graded helped / hurt / stale on each run; hurt and stale learnings are suppressed immediately, so bad advice can't haunt future runs.
• Failed approaches carry an explicit instead, do this alternative — the next run sees both what failed and what to try instead.
• Failures are classified by cause: infrastructure and tooling failures route to operator feedback instead of polluting the plan's memory, because the planner shouldn't try to prompt-engineer its way around a broken server.
• Learnings deduplicate semantically and rank by recency, frequency, and a boost for human-authored guidance. A vector index enables retrieval by relevance, not just recency.

3. Plans that evolve themselves — with an audit trail. The review can recommend plan changes. Changes judged safe are applied automatically as a new auto-regenerated plan revision for future runs — the executed snapshot is never rewritten, provenance is recorded, and every amendment is inspectable and reversible. Bigger changes surface to you as suggestions. A plan changing between runs without an operator touching it is a feature, not a bug — it is the product's core promise, mechanized: the system improves its own playbooks, on the record.

Operators participate too: you can attach guidance to specific milestones, and it survives plan regeneration by matching milestone families rather than exact IDs — your instructions outlive the plan version they were written on.

Why triggers? Because “on a schedule” only covers half of real work. The other half starts when something happens: a webhook fires, an urgent email arrives, a customer submits a form, an SMS comes in. If a human has to notice the event and press Run, you've automated the work but not the waiting for work — often the more expensive part.

Agnticr jobs can start four ways: manually, on a schedule, on demand via the API, or from a trigger:

• Webhooks with real authentication (shared secret or HMAC signature), friendly readable URLs, and provider-retry deduplication.
• Hosted forms — public, password-protected, or Google-allowlisted — whose fields default straight from the job's declared inputs.
• Email and SMS addresses that feed events into jobs.

The differentiating move: triggers are configured in plain language, like everything else. You describe what should start the job — “when a support email mentions an outage” — and an AI evaluator reads each incoming event semantically, decides if it matches, and extracts the job's startup inputs from the payload. No field-mapping spreadsheets (though exact field paths exist as an advanced option). Every accepted, rejected, and blocked event lands in an audit trail with masked content.

Underneath, delivery is durable: incoming events are accepted and safely queued before any processing, so a crash in downstream evaluation never loses an event — the provider gets a success answer only when the event is safely persisted (Chapter 20).

Why a workspace? Because a job that starts from zero every run isn't an employee, it's a temp on their first day — forever. Real recurring work accumulates assets: a template built in week one, a contact list refined in week three, notes about that one supplier who answers only on Thursdays. The workspace is where a job's work compounds.

Every job gets a durable, per-job substrate:

• Files that persist across runs — templates, exports, references.
• A per-job knowledge base the agents search automatically during that job's runs.
• An agent scratchpad — freeform cross-run working memory the agent reads and updates itself, injected into every milestone brief as “your working memory.” The agent's own notebook, in the most literal sense.
• Reusable scripts in three tiers — a platform catalog of sandboxed system scripts (dedup, grouping, aggregation, CSV work), tenant-wide scripts, and job-specific ones — so deterministic data chores run as code, not as expensive and fallible token generation.
• Structured results written to the shared project database (Chapter 14) where they're browsable and queryable beyond the job, while interim scratch stays in a job-scoped area that never clutters your tenant's data.
• An activity feed merging runs, file changes, database writes, and knowledge uploads into one timeline — the job's own newsfeed.

And because the planner sees the workspace inventory at plan-generation time (Chapter 6), the loop closes: the job knows what it already has and plans to extend it.

Watching the job: custom dashboards

A job you can't see is a job you don't trust. Beyond the built-in views, operators can build their own dashboard widgets for a job — by describing them in plain language. “Show me daily execution count this month” becomes a generated, versioned chart widget. The security story is stricter than it sounds casual: widgets run in a fully sandboxed frame with no network access at all, and their only input is a governed metric catalog (execution counts, costs, token usage, message counts, database rows, learnings) that re-checks visibility server-side on every query. You get bespoke dashboards with none of the “operator-written code” risk.

Why connections? Two pains at once. First: an assistant that can't touch your real Gmail, Dropbox, or calendar can only describe work, not do it. Second: the naive fix — pasting credentials into a chatbot — is a security incident waiting to happen. Connections solve both: real access, with the AI never seeing a secret.

• Built-in providers: Gmail, Google Drive, Google Calendar, Dropbox, Microsoft 365 (Outlook Mail, OneDrive, Outlook Calendar, Teams), and classic IMAP/SMTP mailboxes. OAuth wherever the provider supports it — no password ever stored; credential-based IMAP for everything else.
• Custom MCP servers: register your own MCP endpoint with any auth mode; the platform validates it, discovers its tools, and relays traffic so upstream secrets never leave the backend.
• Server-side credential injection. Tokens are encrypted and held by the backend, which injects them at the moment of the tool call. Agents discover and call operations; they never handle credentials. This isn't a policy — it's the architecture.
• Access policies. Folder, label, and calendar allowlists; sender-identity restrictions; per-operation permissions (read / send / modify) enforced at the boundary — not left to the model's good behavior.

Connect once, and every chat session and every job can use the connection — governed, logged, revocable.

Why? Because the most valuable systems in your company are often the ones nobody else has: the internal ERP, the homegrown booking system, the vendor API with your negotiated contract. If your AI can't operate those, it can't do your actual work.

Register an OpenAPI spec (URL or file) plus credentials — Basic, API key, JWT, or OAuth2 client-credentials — and Anders, the API consumer agent, gets a disciplined workflow:

• Search, don't slurp. The platform indexes the spec; Anders searches for relevant operations and loads details on demand. A 400-page spec never floods the context window.
• Allowlists rule. You control allowed HTTP verbs and explicitly allowed/blocked operations. The agent physically cannot call what you didn't permit.
• Credentials injected server-side, with masked request/response summaries in the execution logs. Secrets appear in neither the agent's context nor the audit trail.
• A testbed for humans. Admins can dry-run operations before agents ever use them, and playbooks capture multi-step operation sequences.
• Resilient specs. Spec snapshots are versioned; if your spec source goes down, the last valid snapshot keeps working.

Why give agents a real database? Because structured business data pasted into a chat is data you've already lost — unqueryable, unshareable, gone when the session ends. Work products deserve a home with the properties of a database: persistence, queries, dedup, and an audit trail.

Davie manages a tenant-scoped document database with three visibility levels — tenant (org-wide), project, and job (interim execution scratch, kept out of your browsing views). Agents insert, update, query, and soft-delete records through governed tools; operators browse and manage collections in the UI.

Details that matter more than they sound:

• Server-side aggregation — counts and grouping happen in the database, so the agent reasons over answers, not over ten thousand raw rows (cheaper and more accurate).
• Schema discipline — additive optional fields evolve a collection; incompatible type changes are rejected.
• Built-in similarity checks catch duplicates before they enter your data.
• Soft-delete with a recovery window — agents can't permanently destroy data with one bad call.

Why? Your policies, product sheets, past decisions, and templates are what make your answers yours. No model was trained on them — so the platform grounds agents in them at answer time.

Upload documents into named knowledge collections at tenant, project, or job scope; they're indexed for semantic search. Agents search all in-scope collections with one tool; a job's own knowledge base is automatically included in that job's runs. Files show their processing status, so “why doesn't it know this yet?” has a visible answer.

Why? Here's a way to see it: other platforms hand agents a search box and a text editor, then are surprised when the agents only produce paragraphs. Humans are effective at work because they have software — purpose-built products with their own data and processes. Agent Services are micro-SaaS products whose primary user is an agent.

Each service is a self-contained app inside Agnticr — its own data, its own workspace UI, its own capabilities — that agents use as naturally as a human uses software:

• People Coordination — Pat runs a real coordination process across a group of people, and the job durably waits on the outcome — for days if needed — then continues the moment it lands. Tell Pat the acceptable window in natural language (“weekday afternoons next week, priority: the CFO”), and Pat emails participants, interprets their availability, scores candidate slots by overlap, reminds non-responders on a cadence until a cap, proposes options, and confirms only when every required participant has explicitly accepted. Operators watch the whole negotiation in a live console — and can reopen it for rescheduling any time before the date. Scheduling a meeting across five calendars stops being your problem.
• External Agent Conversations — goal-driven correspondence with people outside your company. Jack drafts, sends, interprets replies, asks follow-ups, and drives the thread toward its declared outcome — negotiating a delivery date, collecting a missing document — ending in an honest business state (completed, counterpart declined, expired with no response), never a dangling thread. Outreach can fan out: one parent request spawns a conversation per recipient and completes when all of them resolve. Operators can nudge, remind, close, or take over at any point.
• A growing catalog — services snap into the platform through a thin contract: each declares its identity, tools, agent persona, workflows, and UI, and the platform discovers it automatically. Services can run inside the platform or fully externally, own their own storage, and authenticate with tenant-scoped access baked into every query. Third parties can build them.

The deep point: this is how Agnticr solves non-generic problems. When your business needs a capability no general-purpose model has, the answer isn't a longer prompt — it's a product the agents can use.

The recurring phrase in this book is by construction: the safety properties aren't policies asking the AI to behave — they're places where unsafe behavior has no code path.

• Credentials never reach the AI. All connection and API secrets are encrypted at rest, held by the backend, and injected server-side at call time (Chapters 12–13).
• Tenant isolation at the platform level. Every record, query, and route is tenant-scoped — enforced in the platform's data layer, not left to convention. Your data can't wander into someone else's answers.
• Multi-tenant, role-based, project-scoped access. Users belong to tenants with per-tenant roles, onboard via single-use invite tokens, and work within projects. One person can hold different roles in different tenants.
• Allowlists over trust. Connection policies, API operation allowlists, and tool-risk gates mean the agent's reachable surface is what you granted — not what it can imagine.
• Untrusted content is data, not instructions. Agents constantly handle content authored by outsiders — inbound email, web pages, fetched documents. A platform-wide constitution hardens every agent against prompt injection: instructions embedded in outside content are treated as material to reason about, never orders to follow. The gate protocol backs this up structurally — even a manipulated agent cannot skip a declared approval.
• Metadata-only telemetry. Usage events, system logs, and audit trails carry token counts, identifiers, and timestamps — never prompt or response content. The log store rejects payloads containing conversational content at ingest. Audit events (every login, every user/tenant/job mutation) are retained on their own schedule.
• Deterministic document generation. When Teddy produces a PDF, spreadsheet, or Office document, it comes from deterministic document libraries — not from arbitrary code execution.

Why itemize? Because “AI subscription” is a black box, and black boxes don't survive budget review. If a job is an employee, it should have a payslip and a performance number.

• Per-run cost, itemized. Every agent turn is metered (tokens, model, agent, scope), priced, and attributed to the tenant, project, job, and execution. Every run's cost panel reads like a taxi receipt.
• Budgets without handcuffs. Monthly budgets with alert thresholds (alert, not auto-block — nobody wants payroll to stop mid-sentence), top-ups, and carry-forward of unused budget, all on a persistent monthly ledger in your timezone.
• Time saved, measured. Each run computes estimated human time (from the plan) versus actual worked time (elapsed minus the intervals spent waiting on humans), yielding time saved and a time multiplier per run and cumulatively per job. The ROI conversation comes with numbers attached.
• Cost discipline inside the engine. Context caching, bounded tool output with retrieve-on-demand, sub-agent isolation for bulk data, and server-side aggregation attack the real cost driver — repeated context — so the receipts stay small without quality loss.

Every industry that matters has a system of record. Accounting has the ledger; law has the docket. When AI performs real actions in the world on a business's behalf, something must be the authoritative record of what was planned, what was approved, what was done, what it produced, and what it cost. That is the role Agnticr claims: the durable, governed, model-neutral execution-of-record for the AI back office.

Concretely, for every execution the platform persists: the frozen plan snapshot that ran (immutable — improvements become new revisions, never rewrites), every human decision with its channel and interpretation, every milestone's deliverables and per-criterion assessment, which agents and models participated, all side effects with idempotency keys, the adjudicator's verdict, the review, the learnings, and the itemized cost.

This framing also names what compounds and doesn't commoditize as models improve:

1. 1.Execution-of-record for governed business actions — gates, side-effect safety, and the completion contract. Model vendors won't own the consequences of real-world execution; Agnticr does.
2. 2.Per-tenant institutional memory — plan memory, reviews, and learnings are private to you and accrue with every run. Nobody else's model gets smarter about your business.
3. 3.Model neutrality — every model seat is routable; better models make the product better, on your terms, without re-platforming.
4. 4.The per-milestone audit trail — evidence preserved at the grain where accountability lives.

Why several services instead of one? Because the platform has three genuinely different jobs — talking to humans, running intelligence, and guarding data — and each wants a different toolchain, failure profile, and deployment cadence.

• The web app owns the human surface: chat, dashboards, the job workbench, settings. It is also a strict proxy boundary — your browser never talks to the backends directly.
• The agent runtime owns the intelligence: Agnes and the specialists, their tools and guardrails, chat sessions and streaming — and the durable workers that execute jobs, triggers, coordination, and external conversations.
• The system of record owns the data: authentication and tenant access control, jobs and plan revisions, connections and encrypted credentials, the document database, knowledge management, usage and billing. It is the only service that touches the data stores directly.

Supporting them, a small set of infrastructure, each present for a reason from this book: a durable workflow engine so jobs survive anything and wait indefinitely (Chapter 7); a relational system of record for tenants, jobs, plans, and audit; a durable message queue so incoming events and billing telemetry are accepted and persisted before they're processed (Chapter 10) — and never slow down a chat; and a document database and vector search for your structured data (Chapter 14) and knowledge (Chapter 15).

Cross-service requests carry a correlation ID end to end, so one identifier follows a request from a browser click through the proxy, the agent, the workflow, and the database write.

Why route models at all? Because “use the best model for everything” is how you get top-tier bills for routine work, and “use the cheap model for everything” is how you get cheap judgment — the most expensive thing there is. The platform's answer is seats: every distinct model call in the system is a named seat, individually routable to a model by configuration.

• High-frequency, low-stakes seats run fast, inexpensive models.
• Judgment seats — the final quality verdict, approval interpretation, learning consolidation, plan evolution — run a stronger judgment tier. This is a product principle, not just a cost dial: quality verdicts, plan evolution, and interpreting a human's “yes but…” are judgment problems, and judgment problems go to models that can exercise judgment.
• Escalation on declared need — the planner marks analysis-heavy milestones for high reasoning effort, and the engine escalates those to a stronger model at runtime.
• Vendor-neutral by design — any seat can route to any provider's model, so the platform rides the model-quality curve without re-architecture (Chapter 19's model neutrality, mechanized).
• Validated before shipped — an evaluation harness with production-shaped test cases gates any seat re-routing on measured quality, not vibes.

Why open the platform to other AIs? Because your team already lives in other tools — Claude, Cursor, custom agents — and an AI back office that only answers its own doorbell is a silo. The tenant MCP API makes Agnticr a tool that other AIs can use.

Every tenant gets a public MCP endpoint, authenticated by API key or full OAuth 2.1, with the tenant resolved from the credential — never from a tool argument, so no client can reach across tenants. The tool surface spans the product: create and run jobs, chat with Agnes, answer approvals, query data and knowledge, read workspace files, inspect execution traces, and pull usage and cost. Your Claude session can ask “what did the invoice job do last night and what did it cost?” — and get the answer from the execution of record.