Agentic

"Agentic" gets used to describe almost anything with an LLM in it now, which makes it a useless word unless you define it once and stick to the definition. Anthropic's own framing is a good starting point: a workflow is a system where you, the developer, define the code paths the model runs through — retrieve, then summarize, then classify, in an order you chose. An agent is a system where Claude directs its own steps — it decides what to do next, calls a tool, looks at the result, and decides again, until the task is done or it gives up. Most systems that call themselves agentic are actually workflows with an LLM call in one step, and that's often the right choice. This post is about the cases where it isn't, and how to build the real thing.

What actually makes something agentic

The distinguishing feature isn't "it uses tools" or "it loops." It's that the model is making the control-flow decisions, not you. A fixed pipeline that always retrieves, always summarizes, and always formats the output the same way is a workflow, even if every step is an LLM call. An agent is open-ended: the number of steps isn't known in advance, the order isn't fixed, and the model is the one deciding when it's actually finished. That open-endedness is exactly what makes agents powerful for ambiguous, multi-step problems — and exactly what makes them slower, more expensive, and harder to test than a workflow.

Four ways to build one

Once a task genuinely needs an agent, there are four distinct ways to build it, and they differ on two independent axes: who writes the loop (the "harness"), and who runs it (the deployment).

• A manual loop you own end-to-end. You write the while stop_reason == "tool_use" loop yourself, call the model, execute whatever tool it asked for, feed the result back, repeat. Maximum control, no dependency on any loop-management feature, and the right choice when your control flow doesn't fit a more opinionated harness.
• A tool-runner style helper. You still define the tools and host the compute, but the loop itself — call the model, execute the tool, feed the result back, repeat until done — is handled for you by the SDK. This is the sweet spot for most custom-tool agents: you're not hand-writing loop plumbing, but you still own every tool the agent can call.
• A managed agent platform. Instead of you hosting the loop and the execution environment, the platform runs both — the agent loop and a sandboxed workspace (bash, files, code execution) the agent acts on. Agent configurations are persisted and versioned, sessions reference them, and the whole thing can run unattended on a schedule instead of only in response to a chat message. This is the right call when you want the loop and the infrastructure to be someone else's problem, or when you need long-running, persisted, or scheduled agents.
• A batteries-included coding/filesystem harness. Built for the case where the agent's job looks like what a developer does at a terminal — reading and editing files, running shell commands, searching a codebase — with those tools and the loop already built in. The right choice when the task is genuinely "operate on a filesystem/repo," not a fit for arbitrary custom-tool agents.

None of these is strictly better than the others — they trade off how much of the loop and the infrastructure you want to own versus hand off.

Should you even build an agent?

Before picking one of the four options above, it's worth checking the task against a shorter list, because the honest answer is often "no, use a workflow":

• Complexity — is this task genuinely multi-step and hard to fully specify as a fixed sequence in advance? If you can write the steps down in order and they don't change, that's a workflow.
• Value — does getting this right justify the extra cost and latency an agent loop adds over a single call or a fixed pipeline?
• Viability — is the model actually reliable at this specific kind of task? An agent doesn't fix a task the model is bad at; it just gives it more chances to be bad at it.
• Cost of error — if the agent gets a step wrong, can that be caught and recovered from (tests, a review step, an easy rollback), or does a bad step cause real damage? Low recoverability is a strong argument for keeping a human in the loop or not going agentic at all.

If the answer to any of these is no, a single call or a workflow is very likely the better engineering decision, not a consolation prize.

The building blocks that actually matter

Assuming the checklist says yes, a handful of design decisions determine whether the agent is reliable or a source of surprise bills and bad outputs:

• Tool design. Fewer, well-scoped tools beat many overlapping ones. If two tools could plausibly both be the right choice for a given step, the model will sometimes pick wrong. A tool's name and description are doing a lot of the reasoning work for the model — treat them like an API's public interface, not an implementation detail.
• Context management over a long-running loop. A loop that runs for many turns accumulates tool results and reasoning that eventually don't fit — or don't need to fit — in context anymore. There are genuinely different tools for this, not one: compaction summarizes older history to make room, context editing clears out old tool results or reasoning you no longer need verbatim, and a separate memory mechanism persists specific facts across turns or sessions on purpose. Picking the wrong one for the problem either loses information you needed or wastes tokens keeping information you didn't.
• Letting the agent pace itself. A hard max_tokens ceiling cuts a response off mid-thought with no warning. Giving the loop a token budget it's aware of lets it wrap up gracefully instead of getting truncated — a materially different failure mode for anything long-running.
• Fan-out with sub-agents. Some tasks are really several independent sub-tasks — research across many sources, a per-file transformation across a repo — where one agent doing everything serially fills its own context with reading it didn't need to keep. Delegating those sub-tasks to separate agent runs, potentially on a cheaper model, keeps the main loop's context focused on synthesis rather than raw legwork.

Reliability and guardrails

The open-endedness that makes agents useful is also what makes them risky, so a few guardrails are worth treating as defaults rather than afterthoughts:

• Approval gates for anything irreversible. Sending an email, deleting a record, pushing code — actions with real-world consequences should pause for a human check rather than run inside the autonomous loop, at least until the agent has a track record.
• Tune effort to the step, not the whole agent. Most genuinely agentic, long-horizon work benefits from running the model at higher effort — it's worth the extra cost when a wrong turn early in a long loop compounds. Cheap, throwaway sub-agent steps (a single lookup, a simple classification) don't need that and can run at lower effort without hurting the outcome.
• Evals, not vibes. "It felt better in my testing" isn't a way to know whether a prompt change or a new tool actually improved an agent's behavior. Running changes against a real eval set is the only way to tell a genuine improvement from a lucky run, especially once the loop has enough steps that a single manual test isn't representative.

Where this is heading

The natural next step past "an agent that responds when a person messages it" is an agent that runs on its own schedule — nightly reports, periodic monitoring, recurring cleanup tasks — with no chat message triggering it at all. That's a small conceptual jump from everything above (it's still an agent making its own step-by-step decisions), but it changes what "guardrails" and "approval gates" need to mean when there's no human in the loop by default to ask.

Agentic is a durable topic precisely because it's a pattern, not a product — the RAG post on this blog is one concrete example of applying it to a single, specific problem (retrieval), and most of what shows up here will end up being another instance of the same four-option decision and the same should-you-even-build-one checklist, applied to a different task.