For six articles this series has treated the agent as something you sit in front of: you open a session, you steer it, you watch the diffs land, you approve and correct. That interactive loop is where most engineers meet agentic coding, and it is genuinely useful. It is also the smallest version of what the technology can do. The bigger shift, the one that changes how a team builds software rather than how an individual types, comes when the agent stops being a thing you drive and becomes a step in a pipeline that runs without you.
The bridge across that gap is a headless, non-interactive mode: a way to invoke the agent from a script with a single prompt and have it return its output and exit, with no terminal session and no human at the keyboard. Once that exists, the agent can be wired into the same machinery as everything else: continuous integration, scheduled jobs, webhooks, bespoke applications. And the same building blocks the series has been assembling (context, tools, permissions, subagents) become the components of automation rather than the controls of a conversation.
This final article is about that transition and the discipline it demands, because the moment an agent runs unattended, every loose assumption you got away with interactively becomes a liability.
From a session you drive to a step you invoke
Interactive use has a safety net you rarely notice: you. When the agent proposes a risky command, a prompt appears and you decide. When it wanders off the task, you redirect it. When it produces something wrong, you catch it before it lands. Headless mode removes that net entirely. A non-interactive run takes a prompt, executes to completion, prints a result, and terminates. There is nobody to answer a permission dialog at three in the morning.
That single fact reshapes everything. The whole design discipline of this series (give the agent good context, expose the right tools, set tight permissions, verify the output) was advisable when a human was in the loop. Unattended, it is mandatory. The agent that runs in CI is the same actor as the one in your terminal, only with the supervision removed, and it has to be engineered accordingly.
An interactive agent is supervised by a human who can intervene at any moment. A headless agent is supervised only by the system you built around it before it started. Everything you forgot to specify is something it will decide for itself.
Putting an agent in the pipeline
The natural first home for a headless agent is the place teams already run automation: continuous integration. A handful of patterns recur, and they share a shape: a narrow task, scoped permissions, and output that a human or another job consumes.
- Automated code review. On every pull request, the agent reads the diff, checks it against the project's conventions and known pitfalls, and posts findings as comments. It does not merge; it advises. A human still owns the decision.
- Issue triage. A new issue arrives; the agent classifies it, labels it, links probable duplicates, and asks the reporter for any missing reproduction detail. That turns a backlog of raw reports into something a maintainer can act on quickly.
- Documentation and changelogs. When a release is cut, the agent drafts the changelog from the merged commits and updates the docs that the change touched, leaving a pull request for review rather than committing to the trunk.
- Drafting fixes. For a well-scoped, well-tested defect, the agent attempts a fix on a branch and opens a pull request. The bar for merging is unchanged: tests pass, a human approves.
Notice what every one of these has in common. The agent produces a proposal, and a deterministic gate (a test suite, a review, a merge button) stands between that proposal and anything irreversible. That is deliberate, and it is the principle everything else rests on. The agent is fast and capable but non-deterministic, so you let it generate and you let something dependable decide.
Permissions must be pre-declared
This is where Part 3 of the series stops being advice and becomes a hard requirement. Interactively, an undeclared permission produces a prompt and you answer it. In CI there is no one to answer, so the run has only two honest options: the action was pre-authorised, or it fails. There is no third path where the agent quietly does something nobody sanctioned.
So a headless invocation must carry an explicit, scoped permission policy, declared up front: exactly which tools it may use, which commands it may run, which paths it may write, which network hosts it may reach. It should be an allowlist rather than a blocklist: you enumerate what is permitted and everything else is denied by default. The review job can read the repository and call the comment API; it cannot push, cannot touch secrets, cannot reach arbitrary endpoints. The principle of least privilege, which we apply reflexively to service accounts, applies with exactly the same force to an autonomous agent. Arguably more, because the agent improvises.
Below is the shape of a CI step invoking the agent in headless mode for a review. It is illustrative, since the exact flags differ by tooling and version, but the structure is what matters:
# .ci/agent-review.sh — runs on every pull request
# Non-interactive: one prompt in, structured result out, then exit.
set -euo pipefail
# Capture the change under review.
git diff "origin/${BASE_BRANCH}...HEAD" > /tmp/pr.diff
# Invoke the agent headless ("print" mode): a single prompt, no session.
# --print run once and exit, do not open an interactive session
# --allowed-tools the ONLY tools this run may use (allowlist)
# --permission-mode deny anything not explicitly granted
# --output-format machine-readable so the next job can consume it
agent --print \
--allowed-tools "read,grep,glob" \
--permission-mode "deny-by-default" \
--max-turns 20 \
--output-format json \
--prompt "Review the changes in /tmp/pr.diff against our conventions.
Report correctness bugs and security issues only.
For each: file, line, severity, one-line explanation.
Do NOT modify files. Output findings as JSON." \
> /tmp/review.json
# A deterministic step — not the agent — decides what happens next.
post-pr-comments --from /tmp/review.json
# Optionally gate the merge on severity, or leave it purely advisory.Read what is not there. No write tool. No shell. No push. The agent can look and report, and that is all. If the prompt somehow convinces it to try, the permission layer refuses, and the run fails loudly rather than succeeding quietly in the wrong way. That is the posture every unattended agent should adopt: capability bounded in advance, failure preferred over unsanctioned action.
Building your own agents on the Agent SDK
CI is automation around a packaged agent. The next step is building automation that is an agent: your own application, with your own tools, your own guardrails, running on the same underlying harness that powers the interactive tool. That harness is exposed as an Agent SDK, available for TypeScript and Python, and it is where the earlier parts of this series come together.
Everything the earlier articles covered stops being a feature of someone else's product and becomes a primitive you compose. Context management, the tool and MCP interfaces, the permission model, subagents for parallel or isolated work: these are now your building blocks. Instead of prompting a chatbot in a loop, you are assembling a bespoke agent whose behaviour you define and whose boundaries you own.
A minimal sketch (again schematic, not a literal API) captures the essential moves: a system prompt that gives the agent its role and judgement, an explicit set of allowed tools, and the limits that keep it bounded.
// build a bespoke agent on the harness (TypeScript-flavoured pseudo-code)
import { createAgent, runAgent } from "@anthropic-ai/agent-sdk"; // schematic
const triageAgent = createAgent({
// The system prompt is the agent's brief: who it is, what "done" means,
// and where the edges are. This is your context-engineering surface.
systemPrompt: `You triage incoming support issues for a payments service.
Classify severity, identify the likely component, and draft a reply.
You may read the knowledge base and query read-only status APIs.
You may NOT issue refunds, change account state, or email customers
directly — escalate anything irreversible to a human.`,
// Allowlist of tools. The agent's reach is exactly this and nothing more.
allowedTools: [
"read_knowledge_base", // custom tool: search internal docs
statusApiTool, // custom tool: read-only service status
{ type: "mcp", server: "ticketing", scope: "read" },
],
// Guardrails as configuration, not hope.
permissionMode: "deny-by-default",
maxTurns: 15, // bound the loop
costLimit: { usd: 0.50 }, // bound the spend
});
const result = await runAgent(triageAgent, {
prompt: incomingTicket.body,
});
// Your code — deterministic — decides what to do with the draft.
await queueForHumanApproval(result.draftReply);The same four ideas reappear: a clear brief, a bounded tool surface, hard limits, and a human gate on anything that cannot be undone. The SDK does not relieve you of these. It hands you the levers and leaves it to you to set them. Bespoke automation built this way (issue triage, data-pipeline guardians, migration runners, on-call assistants) can be very effective, precisely because you have wrapped a capable actor in constraints fitted to your domain.
Guardrails for unattended agents
I want to state the guardrails plainly, because they are the difference between an agent that is an asset and one that is an incident waiting to be written up.
- Scoped permissions, declared in advance. Least privilege, allowlisted, deny-by-default. The agent reaches exactly as far as the task requires and no further.
- Deterministic checks as the safety net. Hooks, tests, type checks, linters, and policy gates are the dependable layer beneath the non-deterministic one. The agent proposes; the deterministic machinery verifies. If the agent fakes a passing test or skips a check, a hook that runs the real suite catches it.
- Cost and iteration limits. A bounded number of turns and a spend ceiling turn a runaway loop from a budget event into a clean, logged failure. An unbounded autonomous agent is an open-ended bill and an open-ended risk.
- A human gate on anything irreversible or outward-facing. Merging to the trunk, deploying, deleting data, sending a message to a customer, moving money: these stay behind explicit approval. The agent may draft and propose all of them; it commits none of them alone.
None of this is exotic. It is the same operational hygiene we apply to any powerful automated system. The novelty is only that the system in question reasons and improvises, which makes the boundaries matter more, not less.
The architect's evolving role
Step back and the larger change comes into focus. As agents take on more of the execution (the typing, the boilerplate, the mechanical edits, the first draft of nearly everything), the value moves away from production and toward design. That means the design of the software, and also the design of the system around the agent: the context it is given, the trust boundaries it operates within, the verification that catches its mistakes, the orchestration that coordinates several of them.
The scarce skill is no longer the ability to produce code quickly; the agent does that. The scarce skill is judgement (knowing what to build, what good looks like, where the failure modes hide, which actions must never be automated) and the systems thinking to encode that judgement into context, permissions, and checks. An architect who can describe a problem precisely, decompose it sensibly, and design the guardrails that make autonomous execution safe is worth far more in this world than one whose value was throughput. The work shifts from writing the solution to engineering the environment in which a capable, non-deterministic actor can be trusted to write it.
Closing the series
That is the thread running through all seven parts. We began with the agent as a capable but unpredictable collaborator and asked what it takes to make it dependable. The answer was never a clever prompt or a magic setting. It was engineering: giving the agent the right context so it understands the problem; extending it with the right tools and MCP integrations so it can act on the world you care about; constraining it with tight permissions so it cannot act on the parts you do not; layering deterministic checks beneath it so its mistakes are caught; orchestrating subagents so larger problems can be decomposed; and finally wrapping the whole thing in automation so it can run unattended without running amok.
Agentic coding is not magic, and it does not threaten the discipline of engineering. If anything, it gives that discipline a new and demanding subject. The agent is a powerful, non-deterministic actor, and like every powerful actor in a serious system, it becomes dependable only when an engineer surrounds it with good context, tight boundaries, the right capabilities, sound verification, and careful orchestration. Get that scaffolding right and the agent stops being a clever toy and becomes genuinely useful: a teammate that does the work while you do the thinking.
Everyone has access to the best models, so that is not what will separate teams. The ones that pull ahead will be those who treat the agent as infrastructure and build the surrounding system with the seriousness that infrastructure deserves. That system is the architect's craft now, and it is only going to matter more. Build it well.
NK