« Track Overview · Warmup · Hitchhiker's · Deep Dive · Principal Deep Dive · Core Contributor · Staff Notes

Phase 00 — The Agentic Engineer's Mental Model: Trust Boundaries, Reliability & Cost Math

Answers these JD lines: the design-review arithmetic behind every role in jd.md — "reliable agent execution" (Cohere), "reliability, latency, cost" (Cohere/Citi), "least-agentic that works," and the trust-boundary thinking that OpenAI Agent Security and Docker's secure-execution roles are built on.

Why this phase exists

Everything else in this track is a mechanism — the loop, the tool call, the MCP message, the sandbox. This phase is the mental model those mechanisms serve. If you skip it, you will build agents that work in the demo and fall over in production, and you will not be able to say why in an interview. Four ideas do almost all the work:

1. The trust boundary. An LLM emits text. It never runs a tool, moves money, or reads a file — your code does, after deciding to. "The model proposes, the application executes." Draw that line explicitly and every security/reliability property has a home. Draw it wrong and you have an injection or privilege bug no prompt can fix.
2. Reliability compounds. \(0.95^{10}\approx0.60\). Agents are loops over an unreliable oracle, so the number of unverified autonomous steps you can afford is small — and knowing exactly how small is what turns "it's flaky" into a design.
3. Cost and latency are engineered, not observed. Tokens per turn, ReAct's quadratic context growth vs ReWOO's linear, p95 vs the mean — you predict these before the build, not after the bill.
4. Least-agentic that works. Most tasks called "agents" are workflows: a known, non-branching path you should hard-code for determinism and cost. Reach for autonomy only when the task genuinely needs runtime flexibility.

Concept map

• Trust boundary: model (untrusted text) → your validator → your executor (trusted action). Everything in Phases 02/03/09/10/13 lives on one side of this line.
• Reliability math: independent-step compounding \(p^n\); the retry lever \(1-(1-p)^{r+1}\); the step budget \(\lfloor\log target/\log p\rfloor\).
• Cost math: tokens = f(system, task, reasoning, observations, steps); ReAct quadratic vs ReWOO linear; output tokens priced 3–5× input; $/resolved-task = unit_cost / success_rate.
• Latency math: sequential chains sum; the tail (p95/p99) is the SLO; budgets are checked at the tail.
• The decision: workflow vs agent vs agent-with-guardrails.

The lab

Integrated scenario (how this shows up at work)

A PM wants an "autonomous agent" to reconcile invoices: fetch each invoice, match it to a PO, flag mismatches, and email finance. You whiteboard it: the path is known (fetch → match → flag → notify), there's no runtime branching, and per-step reliability is ~0.97. Your calculator says: this is a workflow, not an agent — hard-code the four steps, get determinism and a tenth of the cost, and reserve the LLM for the one genuinely fuzzy sub-task (reading a messy PDF). You just saved the quarter's token budget and a class of 2 a.m. pages, and you can defend it with numbers. That is the Staff-level move this phase trains.

Deliverables checklist

• Lab 01 green under LAB_MODULE=solution pytest and your own lab.py.
• You can whiteboard the 0.95^n curve and state the step budget for a target.
• You can explain ReAct-quadratic vs ReWOO-linear token growth from the formulas.
• You can run the workflow-vs-agent decision out loud on a new task.

Key takeaways

• The trust boundary is the first thing you draw and the last thing you compromise.
• Reliability is a budget you spend; every later phase (durability, evals, critics, HITL) exists to buy steps back.
• The mean is a liar; design to p95.
• The most senior thing you can say in an agent design review is often "this shouldn't be an agent."