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 holds a company together, and each of the usual options for it falls short in its own way:

1. 1.Do it manually. It is expensive, slow and error-prone, and it wears down the person stuck with it.
2. 2.Automate it with workflow tools (Zapier, Make, n8n). They are excellent at fixed, high-volume plumbing. But a flowchart works only until reality deviates from it: the supplier replies with a question instead of a confirmation, the spreadsheet grows a new column, the API returns something unexpected. Then the flowchart breaks, often silently.
3. 3.Paste it into a chatbot. Good for a one-off answer, but on its own not enough for work that has to happen reliably every week, with someone accountable for it.

Meanwhile, AI assistants (coding copilots, desktop agents, personal assistants) made one person much faster at their desk. Some now run scheduled tasks remotely and ship enterprise controls, but their unit of ownership remains the personal session or local project. The work does not become a shared company asset that outlives its author, routes decisions to the right colleague, improves its own executable plan, and owes the organization a result.

So in most businesses AI arrives as islands: an agent in one person's browser, a pilot in one department, a flow only the consultant understands. Each helps one person. None of them is part of how the business runs, and nobody owns the whole job.

agnticr exists for that gap. It is the layer between a business and the AI it uses. You delegate a job; agnticr orchestrates who does each step (one of its own specialists, an AI service you already use, or one of your people), asks before anything irreversible, keeps the record, and improves the plan after every run. It fits the AI to the organization you already have, instead of asking the organization to reshape itself around AI.

Two things follow, and they run through the whole book. People lead. They keep the decisions, the judgement calls and the relationships; AI should help them do their work better, not replace them. And you start with one job. Nothing switches over at once: one piece of routine work first, then one part at a time, and nothing you already use has to go.

The one-liner: Delegate the work, keep the decisions. agnticr is one layer that holds your people, a team of agents of its own and the AI you hire together: business jobs that run for hours, days, or weeks, pause to ask a person over WhatsApp when judgment is needed, and learn from every run.

agnticr started from an observation: businesses run this kind of work on people, not on tools. What makes a good colleague valuable is less raw intelligence than a set of qualities that a chat window doesn't have on its own:

• 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. They remember what worked, what didn't, and what you told them, so each week goes a little better than the last.
• They're accountable. You can see what they did, why they did it, and what it cost.

agnticr takes that list literally and builds each quality into software. It builds them around the job rather than around any one worker, so they hold whether a step is done by one of Agnes's specialists, an AI service you have hired in, or a person:

One more quality sits behind the whole table: a good colleague works for someone. In agnticr that someone is you and your people, and everyone else, human or AI, works for them.

The rest of the book explains how each row of that table works.

agnticr is often compared to four kinds of product: copilots and chatbots, workflow tools, agent builders, and other orchestration products. In each case it works together with them rather than replacing them: keep what works, hire it into the team, and let the layer around it supply what a single tool does not.

Copilots, chatbots and desktop agents: hire them in

Many of us use these tools daily. They make individuals faster, and a chatbot is good for a one-off answer. But four things change when the work belongs to a business instead of a person, and those four are what the layer around those tools adds:

1. 1.Durability matters more than location. Some desktop agents now run scheduled tasks remotely, and that helps. The remaining difference is what happens when something breaks. An agnticr job replays after a crash, survives reboots and deployments, 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 work to improve run by run. Desktop tasks typically 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.The work has to belong to the company, not to a person. The better desktop agents are properly enterprise-equipped, with access controls and spend limits. The gap is usually ownership: a session or a local project belongs to whoever opened it. An agnticr job is an organizational asset that colleagues can see, the right person approves, and every run is costed. Credentials stay server-side and agents reach only allowlisted operations.

So rather than swapping them out, hire them in. A Claude or ChatGPT agent you already use can take the steps it is good at inside a job your business owns, with your people in the loop; the job supplies the plan, the owner, the approval and the record (Chapter 4, Chapter 22).

Workflow automation: keep every flow

Zapier, Make, n8n and Power Automate are excellent at deterministic, high-volume data plumbing (sync these rows, forward that webhook), and nothing here asks you to give that up. agnticr does not have a flowchart at all. A zap, scenario, or workflow is a graph that you design, debug, and maintain. An agnticr plan is written by a planner from a conversation. It describes outcomes, typically two to eight milestones, rather than tools and micro-steps, and it is rewritten when a run teaches the job something. A graph changes only when its author edits it.

Approval alone is not the distinction: n8n, Dify, and Power Automate all support approval steps that can wait days for an answer. agnticr's narrower difference is that a gate is declared inside the validated plan, can be answered by live voice, and becomes evidence in the final quality record. When reality deviates, the agents can retry differently, escalate to a stronger model, propose a plan change with evidence, or pause and ask the decision owner.

So keep every flow you have. Agents can call your existing automations through their APIs like any other system, and a flow can start a job through a webhook trigger (Chapter 10). The dividing line is simple: if the work needs judgment, conversation, or approval, it's a job, and your flows are among the things the job uses.

Agent builders: bring the agents you built

Platforms such as Copilot Studio, Lindy, Relevance AI and CrewAI, like a custom agent your own developers wrote, give you a workbench to construct agents: you write the prompts, design the orchestration, wire the guardrails, and keep it all working as models change. That suits teams whose business is building agents, and what they build is valuable. agnticr ships the finished team instead: a planner, named specialists, approval gates, self-improving plans, cost tracking, and tenant-grade governance, already built and integrated, so most businesses never have to build agents themselves. An agent you have built joins that team over A2A (the open protocol agents use to work with one another) and takes its part of a job.

Other orchestration products: what is different

One more category is the closest in spirit. Enterprise process-orchestration suites (Camunda is the well-known example) are strong at durable orchestration, human task lists and external worker queues. AI-workforce builders bring specialist agents, schedules and approval steps. Agent ticket queues are a newer wave of boards where people and agents share work items. And developer frameworks (Temporal, LangGraph and others) are the plumbing underneath; agnticr itself is built on Temporal (Chapter 7).

These are typically built for different readers: process suites for engineers who model the flow in a formal notation, builders for people who wire agents node by node, frameworks for developers. agnticr is built for the owner or operator. You describe the job in plain words and get a readable plan, with no flowchart to draw. What it adds on that side is a team that comes with it, people as first-class steps with work orders, an independent end-of-job judgment (the adjudicator) that decides pass or fail, plans that improve from graded runs, approval gates declared in the plan, and business data stored in the EU. Where one of those products already runs a process you rely on, nothing here forces a choice.

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 easier to follow: “Joel sent 34 emails” reads like a status report from a colleague rather than a log line from a system.

What you get is a staffed team, led day to day by Agnes:

Behind the single chat 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 lowers cost and improves quality, because the orchestrator stays focused on your goal instead of raw payloads.

Hiring in the AI you already use

Agnes and the thirteen specialists come with agnticr and start on day one. They are not the only way work can get done. Your business probably uses some AI already: a Claude agent a developer set up, a ChatGPT agent in the sales lead's browser, a Copilot Studio agent in IT, an n8n flow only the consultant understands, an agent someone built for one task.

agnticr lets you hire those services into the same team. Hiring is not buying and not rebuilding: the service stays where it is, and an AI service you already pay for keeps costing what it costs. What changes is that it becomes a named member of the team for the jobs you choose and takes the steps it is good at, while Agnes's specialists and your own people take the rest. Services such as Claude, ChatGPT agent, Gemini, Copilot Studio, OpenClaw and n8n can be hired in this way, and so can an agent you built yourself.

How a service joins depends on the service. Claude and ChatGPT reach your agnticr over MCP and sign in with OAuth 2.1 (Chapter 22). An n8n flow can start a job through a webhook trigger (Chapter 10). An agent you built yourself joins over A2A and takes its part of a job. None of it asks you to move anything: the services stay where they are, and the jobs, plans and records stay yours.

Start with one. You don't hire a whole roster. Let the team run one job; when a step would be better done by a service you already pay for, hire that service into that step. A week later, hire another. Nothing is replaced in one go, and if you ever stop, the jobs, plans and records are still yours.

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 moves only as fast as 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 (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. 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, whether or not you are there, so you don't have to remember it.

A one-off instruction needs even less ceremony. Say it to Linda on a call, send it on WhatsApp, or forward the email and it becomes a Todo: Agnes picks it up, carries it out, and returns the result on the channel you used. If the same instruction needs to happen again, it graduates into a Job with a reusable plan.

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 in proportion: it retries and resumes where the stream left off (never replaying a message that already went out), brings in a supervisor model to steer past a dead end, or tells you about the problem. You see a brief recovery notice instead of 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, such as “always use Swedish names in this project” or “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.
• Project guidelines. Standing instructions written once per project (your house rules) and injected as system-level guidance into every agent call in that project. They cost nothing when empty, and once set you don't have to repeat them.

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 many tools still today) modeled plans as lattices of micro-steps. That approach fails because 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 owner takes end-to-end, each with declared dependencies, success criteria, deliverables, human gates, and side-effect declarations. The owner is one of Agnes's specialists, a service you have hired in (Chapter 4) or a person, and the plan shows who before anything runs. The plan describes the what; whoever takes the step owns the how, and an agent keeps its reasoning intact.

How it works, briefly:

1. 1.You describe the job in plain language, or ask Mike 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 also 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: mentions and placeholders. Plain language works well 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, and nothing has to guess 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 an execution engine loses its place after a deployment, a crash, or a long human pause, or worse, sends an email twice, it cannot be trusted with business work.

Durable execution is now expected of any serious agentic platform, so it is not the differentiator by itself. What matters is what agnticr builds on that reliable floor: approval, adjudication, learning, and plan evolution.

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

• Crash-proof progress. If a worker restarts mid-job, the workflow replays its history and continues exactly where it was.
• 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.
• A strict 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 that one of agnticr's own agents takes 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 anxiety rather than capability. Few people would let AI email their customers unchecked; most would if it asked first. Gates turn delegation with anxiety into delegation with control, and the rest of the product builds on that.

agnticr's human-in-the-loop system is a protocol built into the engine:

• 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. This does not rely on the model remembering to ask: the engine cannot proceed without the answer.
• Answerable anywhere. Replies come by web, WhatsApp or 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.

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

People are on the team too

Gates are one way people stay in charge. The other is that people are part of the work. When a step needs a person, such as a colleague checking stock in the warehouse or someone in accounts explaining two invoices, it goes to the right one as a work order: what to do, and by when. Their answer comes back into the plan and the job carries on. Nobody has to change how they work to fit in; they get a message, they answer it.

This is the principle behind the whole product: your people lead. They keep the decisions, and Agnes's team, along with any AI service you hire in, takes the routine follow-up and coordination off their hands.

Why is this the differentiating chapter? Self-improving agents are not new: other systems read production runs and propose changes to prompts, tool descriptions, or instructions. The narrower difference is the artifact and the automation together. agnticr changes the executable plan from graded outcomes and applies safe revisions unattended, with the human holding a veto rather than an Apply button. Run the same job ten times and the tenth run is cheaper and better, because the job's operating contract has improved on the record.

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.

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. The result is 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, so 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, and a circuit breaker stops automatic revision if three consecutive changes fail to produce a passing run. A plan that changes between runs without an operator touching it is working as intended: 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, so your instructions outlive the plan version they were written on.

Why triggers? Because “on a schedule” only covers half of the 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, which is 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.

This is also how the automations you already have join in. A flow in n8n, or any other system that can call a web address, can start a job through its webhook. Keep the flows you have; let them hand the part that needs judgment to a job.

What sets triggers apart is that they 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 is like a temp on their first day, every day. 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.”
• Reusable scripts in three tiers (a platform catalog of sandboxed system scripts for dedup, grouping, aggregation and 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.

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 hard to 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 is strict: 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 without the risk of operator-written code.

Why connections? They solve two problems. 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 give real access without the AI ever 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, so no password is 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 is how the system is built, not a policy the agents are asked to follow.
• Access policies. Folder, label, and calendar allowlists; sender-identity restrictions; per-operation permissions (read / send / modify) enforced at the boundary rather than left to the model's good behavior.

Connect once, and every chat session and job can use the connection, which stays governed, logged and revocable. Connections are how the team reaches your systems; hiring (Chapter 4) is how the AI you already use joins the team.

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 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 as good as lost: you can't query or share it, and it is 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? An agent handed only a search box and a text editor mostly produces 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, with its own data, workspace UI and 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). It ends in a clear business state (completed, counterpart declined, expired with no response) rather than 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.

This is how agnticr solves non-generic problems. When your business needs a capability no general-purpose model has, agnticr gives the agents a product to use rather than a longer prompt.

Note the distinction: an Agent Service is an app that lives inside agnticr and is used by agents. A hired service is an AI from outside that joins the team (Chapter 4). They are different things that happen to share a word.

The recurring phrase in this book is by construction: rather than relying on policies that ask the AI to behave, the system is built so that 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 rather than 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 can reach only what you granted.
• 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 (they alert rather than auto-block, so work does not stop mid-task), 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 target the main cost driver, repeated context, so the receipts stay small without quality loss.

Mature fields of work keep 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 work a business delegates, whether a specialist, a hired service or a person does the step.

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, hired services and models took part, 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 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, which ends up costing the most. 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 as much as a cost setting: 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.

Why open the platform to the AI you already use? Because your people already work in other tools (Claude, ChatGPT, Cursor, custom agents), and a layer reachable only through its own app would be a silo. Orchestrating the AI a business uses means being reachable from it: the tenant MCP API makes agnticr something that the AI you already use can work with. Your jobs, plans and records stay yours either way.

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. Claude and ChatGPT both connect this way, signing in with OAuth 2.1.

MCP is how the AI you already use reaches agnticr. Agents you have built yourself have their own door: they join over A2A, the open protocol agents use to work with one another, and take their part of a job (Chapter 4). Neither door changes who the work is for: jobs keep their plans, their gates and their record, and your people still lead.