Agentic Systems: An Operating Manual for Multi-Agent Work That Ships

An agentic system is not a chatbot with plugins. It is a production machine that plans, calls tools, checks its own work against criteria you defined, and stops when it should stop. If you cannot name the evaluator, the sandbox boundary, the state machine, and the kill switch, you do not have an agentic system. You have a demo.

This manual is how Spurlock Studios builds agentic work that founders and technical buyers can put on real data. It is the parent piece for the agentic lane. The spokes go deep on evaluators, sandboxes, state machines, RAG contracts, memory, handoffs, cost, pilots, observability, and when not to build an agent at all.

What is an agentic system?

An agentic system is software that can choose steps toward a goal, use tools to change the world outside the model, and revise its path when evidence says the last step failed — under constraints you own.

Three properties separate it from a scripted automation:

1. Choice under uncertainty. The system picks the next action from a set of allowed tools and states, not from a fixed graph of “always do A then B.”
2. External effects. It can read and write systems you care about: tickets, CRMs, inboxes, code, calendars, knowledge stores.
3. Judgement that is not the worker. Something other than the same context that produced the artifact decides whether the artifact is acceptable.

n8n fits here as the rail for deterministic glue — webhooks, queues, retries, human approvals — while models and tool runners sit inside bounded steps. The rail is boring on purpose. The agent lives in the steps where choice is required; the rail owns delivery, idempotency, and escalation.

If your “agent” is a single prompt that calls three APIs and always returns green, call it an automation. Language matters because budgets, risk reviews, and success metrics change when you admit you are shipping non-deterministic software.

The operating stack (what actually has to exist)

Every production agentic system at Spurlock Studios is built from the same stack. Skip a layer and you will pay for it in production, usually on a Tuesday.

Layer	Job	Failure mode if missing
Job contract	One sentence goal + acceptance criteria	Infinite scope, unmeasurable demos
Evaluator	Independent pass/fail with evidence	Self-grading theater
Tool sandbox	Allowed actions, secrets, blast radius	Agents that can email your customers or delete rows
State machine	Explicit states and transitions	Loops that never halt, duplicate side effects
Memory policy	What persists, what dies with the run	Contaminated context and “it remembered wrong”
Retrieval contract	What may be cited as fact	RAG that invents policy
Handoff protocol	What moves between agents	Lost context, double work
Cost + kill switches	Budgets, caps, abort	Surprise invoices
Observability	Traces, scores, operator dashboard	You cannot debug or trust it

You can implement these in different stacks. The stack is not the product. The contracts are.

Evaluators before agents

Build the evaluator before the agent. That sentence is the whole strategy.

The evaluator is a separate component whose only job is to judge an artifact against criteria. It must not see the worker’s chain of thought. It must return a structured verdict: pass or fail, which criterion failed, evidence, and a next action when fail is recoverable.

Mechanical checks first. Schema validity, required fields, unit tests, allowlisted URLs, “ticket status is one of these enums,” “invoice total matches line items.” Models judge only what genuinely needs judgement: tone for a customer email, whether a summary omitted a material risk, whether a research brief answered the asked question.

Without an evaluator you are optimizing prompts in the dark. With one, every model swap, tool change, and prompt edit becomes a measured experiment.

Deep dive: Build the Evaluator Before the Agent. Related field note (kept separate from this launch cluster): The Evaluator Is the Product.

Tool use only inside sandboxes

An agent without a sandbox is a liability with an API key.

Sandbox means:

• Allowlist of tools, not “whatever the model invents.”
• Scoped credentials — read-only where possible, write scopes only for the tools that must write.
• Blast-radius limits — rate caps, row caps, recipient caps, environment isolation (staging vs production).
• Dry-run modes for first contact with a new tool.
• Human gates on irreversible actions until the evaluator and error rates earn autonomy.

MCP servers and custom tool runners are fine. Unrestricted shell, unrestricted email send, and “admin” CRM tokens are not fine for a pilot.

Deep dive: Sandboxed Tool Use.

State machines where determinism matters

Agent loops need freedom inside a cage. The cage is a state machine.

Typical states for a business agent: intake → plan → act → evaluate → revise → done | escalate | abort. Transitions are explicit. Side effects only happen in act. Evaluation never mutates production systems. Revision has a ceiling (usually three). Escalation packages the full trace for a human.

n8n is a natural home for the cage: each state can be a node or sub-workflow, with durable execution, retries, and a dead path for escalate. The model proposes; the machine decides whether the transition is legal.

Deep dive: State Machines for Agent Loops.

RAG that does not lie

Retrieval-augmented generation fails in businesses for a boring reason: teams treat “retrieved” as “true.” Retrieval is a search result. Truth is a contract.

A retrieval contract answers:

• Which corpora are authoritative for which question types?
• What freshness rules apply?
• Must citations be present for any factual claim?
• What happens when retrieval returns nothing — refuse, ask, or fall back to a human?
• How do you detect contradiction across chunks?

If the agent can invent policy when the index is empty, you do not have RAG. You have a confident liar with a vector database.

Deep dive: RAG That Does Not Lie.

Memory: persist on purpose

Agent memory is not “stuff the whole transcript into the next call.” Memory is a policy.

Separate at least four stores:

1. Ephemeral run context — dies when the run ends.
2. Working scratch — intermediate artifacts for this job only.
3. Durable facts — customer prefs, account IDs, approved SOPs — with ownership and TTL.
4. Run history / traces — for ops and learning, not for raw re-injection into every prompt.

Persist preferences and identifiers. Forget raw intermediate reasoning. Never let a failed run’s bad conclusions become long-term “memory” without a promotion rule.

Deep dive: Agent Memory Patterns.

Multi-agent handoffs without lost context

Multiple agents are useful when jobs naturally split: research vs draft vs compliance check; intake vs enrichment vs write-back. They are harmful when you multiply agents to look sophisticated.

A handoff is a typed package:

• Goal and constraints
• Artifacts produced so far
• Open questions
• Tools already tried and outcomes
• Budget remaining
• Evaluator criteria still unmet

Do not pass “the vibe.” Pass the package. The receiving agent should not need the sending agent’s private scratch.

Deep dive: Multi-Agent Handoffs Without Lost Context.

Cost controls for fleets

Token spend is a product feature. Treat it like one.

Per-run budgets, per-day budgets, max tool calls, max revisions, model tiers by state (plan on a cheaper model, evaluate on a stricter one when needed), and hard kill switches when spend or error rate crosses a line. Log cost on every transition. Ops should see dollars next to failure rates.

Deep dive: Cost Controls for Agent Fleets.

Observability ops will actually read

If the only “observability” is provider dashboards, you will not catch silent wrongness. Traces must show: state, tool calls, inputs/outputs (redacted), evaluator verdicts, cost, latency, and escalation reason. Scores from your evaluator suite should land on a dashboard a human checks weekly — not a graveyard of JSON in object storage.

Deep dive: Observability for Agents.

When not to build an agent

Default to automation when the path is known, the inputs are structured, and judgement is rare. Default to a human when stakes are high and criteria are contested. Build an agent when the path varies, tools are many, and you can still write acceptance criteria crisp enough to evaluate.

Deep dive: When Not to Build an Agent.

Multi-agent architecture for business (a reference shape)

Here is a shape that ships for small and mid-size teams without becoming a research project.

Roles

• Router / intake — classifies the job, attaches the job contract, rejects out-of-scope work.
• Worker — plans and acts inside the sandbox.
• Evaluator — independent judgement; no tool writes.
• Librarian (optional) — retrieval only; returns citations or “no hit.”
• Operator surface — humans approve, abort, or re-scope.

Control flow

1. Event or human request hits intake (often via n8n webhook).
2. Job contract loaded; budget and tool allowlist attached.
3. Worker enters plan → act loop under the state machine.
4. After each material artifact, evaluator runs.
5. Fail → revise until ceiling → escalate.
6. Pass → write-back through allowlisted tools → done.
7. Trace + cost + scores stored for ops.

What “done” means

Done is not “the model said done.” Done is: evaluator passed, side effects confirmed idempotently, and the run landed in a terminal state with a receipt the operator can audit.

How do you evaluate AI agents?

Evaluation is a product discipline, not a vibe check after a demo.

Unit-level

• Tool adapters: given fixture inputs, do they return typed outputs or typed errors?
• Retrievers: precision/recall on a labeled query set for your corpus.
• Schemas: every agent-facing JSON shape validates.

Task-level

Build a golden set of 30–100 real jobs (anonymized if needed). For each: input, required artifacts, pass criteria, known traps. Run the suite on every change that could affect behavior. Track pass rate, average revisions, cost per pass, escalate rate.

Online

Sample production runs. Score with the same evaluator. Alert when online scores drift from offline. Drift is how quiet failures start.

What not to measure alone

Latency and token count without quality. “User thumbs up” without criteria. Self-reported confidence from the worker.

The five-day pilot (how Spurlock Studios starts)

Most teams do not need a twelve-week “AI transformation.” They need one narrow job proven on their data.

The Spurlock Studios agentic pilot is $1,500 · 5 days. One job, scoped tight enough to finish in a week. A working agent on your real data — not a slide deck. You keep it either way. The $1,500 credits toward a full build.

What you leave with:

• A runnable agent for one sentence-sized job
• An evaluator with explicit criteria
• Sandboxed tools for that job
• A short build quote based on what we actually saw

Start on /agentic or go straight to /contact?intent=agentic-pilot.

Scoping detail: Scoping an Agentic Pilot That Proves Value in Five Days.

When the problem is architecture across a roadmap rather than a single agent, that is the fractional AI CTO lane — same principles, different engagement shape. See The Fractional AI CTO Model.

A concrete walkthrough: support triage agent

Job contract: “Given a new support ticket, classify severity, draft an internal summary with citations from the help center, and propose a reply — never send.”

Evaluator criteria (examples):

• Severity is one of P1|P2|P3|P4
• Summary includes at least one citation URL from retrieval or explicitly says “no doc match”
• Proposed reply contains no promise of refund or SLA change unless those strings appear in retrieved policy
• Schema validates

Tools in sandbox: ticket read API, help-center retriever, draft write to internal field. Not in sandbox: send reply, issue refund, change billing.

State machine: intake → retrieve → draft → evaluate → revise (max 3) → escalate or done.

Memory: customer ID and prior ticket IDs may persist; raw model scratch does not.

Cost: hard cap on retrieval calls and revisions; abort to human queue if exceeded.

That system is agentic. A Zap that posts “new ticket” into Slack is not. Both can be valuable. Only one needs this manual.

Failure modes I see every month

Agent theater. Fancy UI, no evaluator, no sandbox, no budget. Demo day works. Week three does not.

Prompt as policy. Rules living only in natural language. Policies belong in code checks and allowlists; language fills gaps.

Unbounded loops. No revision ceiling. Cost and chaos grow together.

RAG without refuse. Empty retrieval still produces “facts.”

Too many agents too early. Three agents before one job is green. Split only after the single-worker path is measured.

No human path. Escalation is a first-class state, not an apology.

Build sequence (do this order)

1. Write the job contract and acceptance criteria with the buyer.
2. Build the evaluator and a tiny golden set.
3. Implement tools behind a sandbox with dry-run.
4. Wire the state machine (n8n or equivalent) with budgets and escalate.
5. Add retrieval and memory only if the job needs them — with contracts.
6. Run the golden set until pass rate and cost are acceptable.
7. Soft-launch with human gates on writes.
8. Widen autonomy only when online scores hold.

Skipping to step 6 because a vendor demo looked good is how you buy regret.

Who this is for

Founders and technical buyers who need work done — triage, research briefs, enrichment, internal ops agents, content drafts with hard constraints — and who will not accept “trust the model.” If you want a public chatbot with no criteria, this is the wrong lane.

Spurlock Studios ships agentic systems with explicit state machines, sandboxed tool runners, and reflection loops that self-correct. Builds typically land in 2 to 10 weeks after a pilot proves the job.

Security and tenancy (non-optional for fleets)

If more than one customer or department shares infrastructure, tenancy is an agent feature. Every run carries tenant_id. Tool credentials are bound to that tenant. Retrieval ACLs filter before ranking. Memory keys are prefixed. Logs are partitioned. A “shared enrichment key” that can see every CRM is a data-breach design.

Prompt injection is a tenancy problem too: content from Tenant A must never expand tools or memory for Tenant B. Sandboxes and allowlists are the first wall; evaluator checks for cross-tenant identifiers in artifacts are a useful second wall.

Human-in-the-loop without freezing the business

Human gates fail when every run waits on a busy founder. Design queues:

• Batch review for soft writes (internal notes) twice a day
• Immediate review only for irreversible classes
• Auto-promote when online pass rate holds for N days on that job type
• Spot checks forever — autonomy is not absence of audit

The operator surface should show the same trace fields ops already use: criteria failures, cost, and the proposed write payload. Asking a human to re-read the whole chat is how gates get muted.

Team roles that keep systems alive

• Job owner — sets criteria and accepts risk
• Systems owner — credentials, schemas, rate limits
• Agent engineer — prompts, tools, state machine
• Ops reviewer — weekly scores and incidents

One person can wear multiple hats at a small company. Zero people wearing the ops hat is how silent failure becomes culture.

Migration path from demo to production

1. Criteria + golden set
2. Sandbox + dry-run tools
3. Thin state machine with budgets
4. Soft writes only
5. Online sampling
6. Widen tools and autonomy
7. Multi-agent split only after single-worker pass rates hold

Skipping to multi-agent product theater is the common failure. The spokes in this cluster exist so you can deepen one layer at a time without losing the map.

Closing the loop

Agentic systems ship when judgement is independent, tools are caged, control flow is explicit, memory and retrieval are contracted, and cost has a kill switch. Everything else is costume.

Read the spokes in the order your risk demands. Most teams should start with evaluators, then sandboxes, then pilot scope. Come back to this manual when you need the full map.

Ready to prove one job in five days? /agentic · /contact?intent=agentic-pilot

Procurement and vendor questions that matter

When a vendor sells you “agents,” ask:

1. Show the evaluator on our sample cases, not yours.
2. Show the tool allowlist and how new tools are added.
3. Show the state machine or equivalent control flow.
4. Show per-run budgets and a kill switch demo.
5. Show a trace with redaction.
6. Show what happens on empty retrieval.
7. Show who owns prompts after go-live.
8. Show exit: can we export and run without you?

If answers are slides without receipts, you are buying theater. The spoke cluster under this manual exists so your team can run the same checklist internally.

Reference glossary

• Job contract — goal, audience, criteria, hard nos
• Evaluator — independent verdict with evidence
• Sandbox — allowlisted tools + caps + least privilege
• State machine — legal transitions and terminals
• Handoff package — typed relay between agents/humans
• Kill switch — automatic stop on spend/error thresholds
• Golden set — labeled jobs for regression

Use the words precisely. Language drift recreates agent theater under new names.

Implementation notes for technical buyers

Treat each layer as a mergeable module with an owner and a test. The evaluator module exports judge(artifact, criteria) -> Verdict. The sandbox module exports callTool(name, args, ctx) -> Result. The state machine exports transition(state, event, ctx) -> State. Memory and RAG export read/write functions with schemas. Observability wraps all of the above.

Integration tests should freeze a run through intake to terminal with fixture tools. Contract tests should freeze golden-set scores on CI. Load tests should freeze budget trips. You do not need a research lab; you need the same engineering hygiene you already use for payments and auth.

When model providers change versions, pin and re-run the golden set before promoting. “Latest” as a default is an availability choice that often breaks quality silently. Pinning is part of cost and risk control, not pedantry.

Document the hard nos in the same repo as the code. Hard nos that live only in Slack will be rediscovered after an incident.

Editorial map of this cluster

Read in this order if you are starting cold:

1. This manual (map)
2. When not to build an agent
3. Evaluators before agents
4. Tool-use sandboxes
5. Agent pilot scope
6. Then state machines, RAG, memory, handoffs, cost, observability as needed
7. Fractional AI CTO model when the problem is organizational, not a single job

The existing field note The Evaluator Is the Product remains a short companion piece outside the launch spine; it does not replace the evaluator spoke.

FAQ

What is an agentic system in plain terms?

An agentic system is software that can choose tools and steps toward a goal, change external systems, and revise when checks fail — under budgets and rules you define. It is not a chat UI. The difference from automation is meaningful choice under uncertainty plus independent evaluation.

How do you evaluate AI agents without fooling yourself?

Separate the evaluator from the worker. Use mechanical checks first, then model judgement only where needed. Maintain a golden set of real jobs and run it on every meaningful change. Track pass rate, revisions, cost per pass, and escalate rate. Never trust the worker’s self-score as the primary metric.

What is a good multi-agent architecture for a small business?

Start with intake, one worker, one evaluator, and an operator path. Add a librarian for retrieval if knowledge is central. Split more workers only after a single-worker path clears your golden set. Prefer typed handoff packages over shared chat transcripts.

When should we use n8n in an agentic system?

Use n8n (or similar) for webhooks, queues, retries, approvals, and state transitions that must be durable and auditable. Keep model calls and tool runners inside bounded steps. n8n is the rail; the agent is the cargo that needs judgement.

How much does an agentic pilot cost at Spurlock Studios?

The pilot is $1,500 for five business days: one narrow job on your real data, a working agent you keep, and a build quote based on what we saw. Details and packaging live on /agentic.

Do we need RAG for every agent?

No. Add retrieval when the job depends on your documents or policies. If the job is pure structured transformation or tool choreography, skip RAG. When you do add it, write a retrieval contract that includes refuse-on-empty behavior.

How do we stop agents from doing dangerous things?

Allowlist tools, scope credentials, cap blast radius, require human approval for irreversible actions until scores earn autonomy, and put kill switches on spend and error rate. Sandboxes are not optional for production tool use.

What is the difference between an agent and an automation?

Automation follows a known path with rare judgement. An agent chooses among tools and paths under uncertainty and must be evaluated. If you can draw the flowchart completely, you probably want automation. If the path varies but criteria are clear, you may want an agent.

How long until a production agentic build ships?

After a successful pilot, Tier-style builds at Spurlock Studios typically land in roughly 2 to 10 weeks depending on tools, memory, evaluation harness depth, and how many agents the workflow truly needs. The pilot exists so that timeline is priced from reality, not slides.

Who owns the IP and the running system after a pilot?

You keep the pilot agent and can run it yourself. Full builds are scoped as your systems in your infrastructure — not a rented black box. Confirm packaging on the engagement docs for your tier; the pilot credit and keep-it-either-way terms are stated on /agentic.