AI Agents and Orchestration for Forward Deployed Engineers

Once a model can use tools, you can put it in a loop: let it reason about a goal, call a tool, read the result, decide the next step, and repeat until it's done. That loop is an agent. It's the most exciting building block, and the most over-reached. The senior skill here is as much knowing when not to build one as knowing how.

The loop is abstract until you watch one run. Here is what a bounded run looks like: an agent asked to find out why a nightly data sync failed, on a budget of five steps (illustrative trace):

goal: find out why last night's data sync failed              [illustrative]

step 1  call  read_log("sync.log")
        obs   ERROR: timeout connecting to vendor API
step 2  call  check_status("vendor-api")
        obs   vendor reports healthy — the timeout is on our side
step 3  call  read_config("sync/network.yaml")     ← replanned from step 2's observation
        obs   proxy points at gateway host "gw-old"
step 4  call  read_config("sync/network.yaml")     ← same call, same plan: the confused-loop smell
        obs   (unchanged)
step 5  call  read_config("sync/network.yaml")
        obs   (unchanged)

step budget (5) reached → stop, return partial result + trace

Two shapes are worth reading off the trace. A healthy step changes because of what the last observation said: step three abandons the vendor hypothesis and inspects the local config precisely because step two ruled the vendor out. The degenerate step repeats an action with no new information and no revised plan. Steps four and five are that failure, what a confused agent looks like from the outside, and more steps would have bought more of the same. That is why the production answer is a budget plus a returned trace: the run ends at a known cost with a partial finding and a replayable record, the bounded-autonomy posture the rest of this page builds out.

Why restraint is the senior signal

The reflex, once you learn agents exist, is to make everything an agent. Resist it. Anthropic's engineering guidance is blunt: it recommends "finding the simplest solution possible, and only increasing complexity when needed". Workflows (fixed, predictable sequences you orchestrate) suit well-defined tasks, while agents suit open-ended problems that genuinely need model-driven flexibility, and agentic systems "trade latency and cost for better task performance" (Anthropic, 2024). An FDE who reaches for a multi-agent system when a two-step pipeline would do has added latency, cost, and failure modes for no gain. In an interview, proposing the simplest thing that works is a stronger signal than proposing the most autonomous.

Before reading on: a customer wants to "extract the invoice number, date, and total from uploaded PDFs." Would you build an agent? Answer before reading the next line.

No. That's a fixed, well-defined task: one extraction step with structured output, maybe a validation step. It's a workflow. Reaching for an autonomous loop here buys you unpredictability and cost with no benefit. Save the agent for the task whose steps you genuinely can't lay out in advance.

Workflow or agent? — the decision

• Use a workflow when you can write down the steps: the path is predictable, so orchestrate a fixed sequence (retrieve → generate → validate). It's cheaper, faster, and far easier to test and debug.
• Use an agent when the steps depend on what's discovered along the way: research that follows leads, debugging that forms and tests hypotheses, a task that needs a variable number of tool calls you can't predict. Here the model's flexibility earns its cost.
• When unsure, start with the workflow, and move to the agent only when a real limitation forces it.

If you do build an agent, bound it

An autonomous loop that can act is exactly the system the guardrails page is about. Bounding is not optional:

• A step budget: a hard cap on iterations, so a confused agent stops and reports instead of looping forever.
• Checkpoints on irreversible actions: the loop runs freely for reversible steps and pauses for a human before anything with real-world blast radius.
• Observability: a trace of the agent's reasoning and every action, so when it goes wrong you can replay exactly where.
• A cost and latency ceiling: each step is another model call, so an agent's bill and wall-clock grow with the loop.

Multi-agent systems (several specialized agents coordinating) exist too, and occasionally a task needs them. But they multiply every one of the above costs, so the bar for reaching for them is higher still.

Bad / Good / Great — "would you use an agent here?"

Bad — "yes, I'd build an autonomous agent that handles the whole thing." Reaching for maximum autonomy by default. On a predictable task it adds cost, latency, and failure modes; the interviewer hears someone who's read about agents but not operated one.

Good — "it depends on whether the steps are predictable; if not, an agent with tools." The right question, which is most of the battle. The gap: no mention of bounding the loop, and no clear default toward the simpler option.

Great — "I'd default to the simplest thing: if the steps are knowable, a fixed workflow, which is cheaper and testable. I'd only use an agent if the task genuinely needs model-driven steps I can't script — and then I'd bound it: a step budget, human checkpoints on irreversible actions, a trace for debugging, and a cost ceiling. Autonomy is a cost I pay only when the task requires it." You led with restraint, named the decision, and bounded the loop. An interviewer hears someone who treats autonomy as a cost to justify, which is the instinct this question exists to find.

What to carry into the interview

When a prompt invites an agent, what's being tested is judgment. State the workflow-versus-agent decision explicitly, default to the simpler option, and if you do go agentic, bound the loop out loud: steps, checkpoints, trace, cost. Choosing the simplest architecture that solves the problem, and bounding autonomy you do grant, is what Anthropic's own guidance points at.

Next: Model Context Protocol (MCP) — the standard for connecting all these tools and data sources to the model without a bespoke integration each time.