Principles I build by

Credential Claude Certified Architect (Foundations), Anthropic These principles reflect how I build agentic systems, and the certification I hold.

Anyone can wire a model to a tool and call it an agent. The engineering is in the rules that hold when no one is watching: how the loop knows it is done, what the system is allowed to touch, how work is split, how output is checked, and what survives once the context gets long. These are the five principles every system on this site is built on, each stated plainly, tied to real work, and paired with the failure it exists to prevent.

Orchestration and the loop
Deterministic guardrails over hope
Tool and interface design
Structured, verifiable output
Context and reliability at scale

The five

Each card states the principle in one line, how I apply it to the systems I actually run, and the anti-pattern it avoids. Expand any card for the applied detail. They are collapsed for a fast scan and fully readable open.

How to read this The orchestrator and think-tank that build my sites, the Lab Orchestrator Console, the two production agents on a robotics data program, and the guardrail safety floor are the systems referenced throughout. Expand a card to see how the principle lands in each.

Orchestration and the loop A coordinator routes to specialists, and the loop advances on the model's stop reason, not on parsed text or an arbitrary cap.
How I apply it
- A coordinator owns the plan and routes each task to the specialist built for it, instead of one model trying to do design, build, and review in one long sequence.
- The loop turns on the stop reason the model returns. A tool-use stop means run the tool and continue; an end-turn means the step is genuinely finished. I never decide that by scanning the prose for a phrase like "all done."
- Subagents run with their own isolated context and hand back an explicit, structured result, so one agent's scratch work never leaks into another's reasoning.
- Independent work dispatches in parallel. On this site the ideation think-tank and the build specialists each fan out at once, then their outputs are gated together.
- Decomposition is fixed when the shape of the work is known. Predictable multi-aspect jobs use prompt chaining with set stages; open-ended investigation gets a dynamic plan the coordinator adapts as it learns.
Anti-pattern Deciding when to stop by parsing natural language, or one model grinding through every role in sequence with no router and no clean handoff.
Deterministic guardrails over hope Where compliance must be guaranteed, it is enforced in code, not requested in a prompt.
How I apply it
- Rules that cannot be allowed to fail are programmatic: hooks and prerequisite gates that run regardless of what the model intends. A gate that has to hold is not a sentence in a system prompt.
- Prompt guidance is reserved for the places where probabilistic is acceptable: tone, phrasing, judgment calls. The cost of an occasional miss there is low.
- Every system sits on a hard safety floor. Routine work runs on its own, consequential work waits for a human, and a short list of actions can never happen at all. The permission model on the home page is exactly this floor.
- Tool calls and their results are intercepted and normalized at the boundary, so a malformed or out-of-policy action is caught and shaped before it ever takes effect.
Anti-pattern Trusting a prompt instruction to hold for rules with financial or irreversible consequences. "Please do not move money" is not a control.
Tool and interface design A model picks tools by their descriptions, so the description is the interface and it has to earn its place.
How I apply it
- Each tool description carries its inputs, its boundaries, and when to reach for it versus an alternative. The model is choosing from text, so vague text produces vague choices.
- Every agent gets a scoped tool set sized to its job. Too many tools degrade selection, so a specialist sees only what its slice needs, not the whole catalog.
- Errors come back structured, with a category and a retryable-or-not signal, so the caller can react correctly. A generic "operation failed" tells the model nothing it can act on.
- Tool choice is set to match the task: auto when the model should decide, any when it must use some tool, forced when exactly one call is correct. The constraint is part of the design, not left to chance.
Anti-pattern Overlapping, vague tool descriptions that blur into each other, plus a uniform "operation failed" error that strips out everything the caller would need to recover.
Structured, verifiable output If a result has to be machine-read, its shape is guaranteed by a schema and checked by something other than the author.
How I apply it
- Output that downstream code depends on is produced through tool use with a JSON schema, so the structure is guaranteed rather than coaxed out of free text.
- Few-shot examples lock in consistency and, more importantly, show the model how to judge the ambiguous cases that a rule alone cannot cover.
- Criteria are explicit and categorical. "Pass, warn, or block against these stated conditions" beats "be conservative," because a vague instruction produces vague and unrepeatable verdicts.
- Output is validated, and on a failure the specific error is fed back for a targeted retry, not a blind re-roll of the whole request.
- An independent reviewer checks the work. The auditor that gates every wave on this site is a separate pass with its own context, because self-review in the same context grades its own homework.
Anti-pattern Filtering on a self-reported confidence score and reviewing the work in the same context that produced it. Both lean on the model to be its own honest judge.
Context and reliability at scale Long runs lose the middle, so the facts that matter are kept out of lossy summaries and confidence is calibrated, not assumed.
How I apply it
- Transactional facts (amounts, dates, identifiers) are preserved verbatim outside any summary. Models lose detail in the middle of long context, so the exact numbers live somewhere they cannot be paraphrased away.
- Verbose tool output is trimmed at the source, before it piles up and crowds out the signal further down the run.
- Claim-to-source provenance is carried through synthesis. A conclusion stays attached to the evidence it came from, so it can be checked rather than taken on faith.
- Confidence is calibrated, and low-confidence work is routed to a human instead of being waved through. The first-pass labeling agent proposes, and a person confirms every call.
- Error context propagates as structure, so a failure deep in the system arrives with enough detail to diagnose, not as a generic dead end.
Anti-pattern Progressive summarization that condenses away the exact figures that matter, then asks the model to act on the blurred version.

How the safety floor actually works

A deeper look at principle 02. Where consequences are financial or irreversible, a rule does not live in a prompt. It lives in code that runs before the action does.

A language model is probabilistic. Ask it nicely to never move money and it will comply almost always, and almost always is precisely the wrong bar when the failure is a real charge or a deleted record. So the guarantee is moved out of the prose and into an interception layer. Every tool call the model proposes is routed through a hook that runs after the model decides but before the action executes. The hook reads the call, checks it against an explicit policy, and returns one of three verdicts: allowed, needs human approval, or blocked. The model never gets a vote on whether the gate runs.

The policy is boring on purpose. Money movement is blocked. Irreversible actions, deletes, sends, anything that cannot be walked back, are blocked or escalated. Anything over a configured threshold needs a human. Everything else passes. Because the check is deterministic code rather than a request, it holds at the same rate every time, on the worst run and the best one, regardless of how the prompt was phrased or how the conversation drifted. That is the whole point: probabilistic compliance is fine for tone and phrasing, where an occasional miss is cheap. It is not fine for the small set of actions where one miss is the only one that matters.

This is the same floor shown on the home page, stated in code. Routine work runs on its own, consequential work waits for a person, and a short list of actions can never happen at all. The pattern below is illustrative, generic pseudocode, not a production implementation, but it shows the shape: classify the call, then act on the class.

Illustrative pattern Generic pseudocode, not production code or any specific framework. The point is the shape: classify, then gate.

# PostToolUse-style hook: runs after the model picks a call,
# before that call is allowed to execute.
def gate(call):
    if moves_money(call) or is_irreversible(call):
        return Block(reason="hard floor: money or irreversible",
                     call=call.name, category="denied")
    if amount_of(call) > APPROVAL_THRESHOLD:
        return Escalate(reason="over threshold, needs a human",
                        call=call.name, category="approval")
    return Allow(category="auto")

# The runtime, not the model, decides what to do with the verdict.
verdict = gate(proposed_call)
if verdict.category == "denied":
    halt(verdict.reason)        # never reaches the tool
elif verdict.category == "approval":
    wait_for_human(verdict)     # pause until a person signs off
else:
    execute(proposed_call)      # routine work proceeds

Where this is the wrong tool

Tradeoffs

It is overkill for simple work. A single-step task with no side effects does not need a coordinator and a gate in front of every call. Wrapping a one-shot read in this machinery just adds moving parts that can themselves break.
Gating has a cost. Every checked call adds a hop, and human-approval steps add real latency measured in minutes or hours, not milliseconds. Gate everything and a fast job becomes a slow one for no safety gain.
The coordinator can become the bottleneck. Route every decision through one central node and it caps throughput. I mitigate that by dispatching independent work in parallel, scoping each agent so it carries less, and gating only the consequential steps. The read-only and reversible majority runs ungated; the floor sits on the actions that can actually hurt.

Failure modes

A misconfigured gate fails open or fails closed. Fail open and a dangerous call slips through; fail closed and safe work is blocked and the system stalls. Neither is acceptable silently, so the verdict and its reason are logged on every call, and the design defaults to deny on an unrecognized action rather than waving it through.
How I test that the floor holds. The gate is covered by its own cases: known-dangerous calls must return a block, over-threshold calls must escalate, and routine calls must pass. The blocked and escalated paths are asserted directly, because a floor you never test against a real violation is a floor you only assume is there.

These are general principles of building agentic systems, applied. The proof is not the list. It is that the systems on this site, including this site, were built under these rules and hold up to a look under the hood.

See them running in the Lab →