Coding Agent Design Workbench
Producing architecture decisions, failure paths, verification methods, and course deliverables across nine system dimensions
THE QUESTION THIS PAGE ANSWERS
ANSWER FIRSTWhat is the key idea behind “Coding Agent Design Workbench”?
Producing architecture decisions, failure paths, verification methods, and course deliverables across nine system dimensions
Make the claim earn its place. Use this page as a decision aid, not a definition to memorize. Connect the idea to one real task, one observable result, and one failure that would change your mind.
Write one question you could answer with evidence after trying this idea.
A conclusion that sounds complete but leaves the key assumption untested.
Coding Agent Design Workbench
The capstone task evolves from a feature list to a runnable system design. Make explicit decisions across nine dimensions — each must include a contract, failure path, validation method, and submittable deliverable.
Course Objectives
Complete System Boundaries
Define the responsibility boundaries of entry points, state ownership, model loops, and external extensions.
Fill in Failure Design
Draw failure paths for tools, security, persistence, recovery, and state notifications.
Produce Reviewable Deliverables
Submit ADRs, contracts, threat models, tests, and a minimal demo — not just conceptual diagrams.
The Complete Agent System at a Glance
Capstone Project Brief
Design a "repo-scale Coding Agent" for a real team. It must at minimum read code, propose a plan, edit files, run validation, and resume interrupted sessions. A minimal PoC is acceptable; the architecture document must cover all nine dimensions.
- Least-privilege by default
- Every external action is traceable
- Crash recovery is explainable
- Sensitive data has a defined landing spot
- Extension code has a trust boundary
Nine-Dimension Decision Cards
Entry Point
Who starts the Agent, and do interactive, CI, and IDE modes share the same core?
Source anchors: pager-bin composition root, shell headless/stdio, ACP gateway.
State / Concurrency
Who owns session state, and how are model streams and tool tasks cancelled, queued, and returned?
Source anchors: SessionActor, LocalSet, background summary/persistence actor.
Model Loop
How do prompts, streaming output, tool calls, retries, stops, and model switches form a closed loop?
Source anchors: run_loop, turn, tool_dispatch, model_switch, two_pass.
Tool Contract
How are input Schema, return values, errors, timeouts, idempotency, and permission tiers standardized?
Source anchors: ToolKind, Tool Bridge, server__tool, capability filter.
Context / Memory
When is short-term context compacted; what is written to long-term memory, when is it retrieved, and how is it deleted?
Source anchors: compaction segments, two-pass, memory FTS/embedding/MMR/Dream.
Security
What guarantee does each layer — permissions, sandbox, Hooks, network, and plugin trust — provide?
Source anchors: capability, sandbox, Hooks fail-open, plugin-root trust.
Persistence / Recovery
How are messages, tool results, file checkpoints, and external connection state persisted and replayed?
Source anchors: session persistence, chat persistence, rewind, MCP restart.
Observability / Privacy
Which events enter logs and metrics; what must be redacted, sampled, or prohibited from leaving the machine?
Source anchors: file-utils events, telemetry enums, MCP status payload.
Extension Ecosystem
How are MCP, Plugin, and Hook discovery, versioning, enablement, trust, and uninstallation governed?
Source anchors: marketplace index, manifest, install registry, trust store.
Real Source Code Evidence Navigation
xai-grok-shell/src/session/acp_session.rs
xai-grok-workspace/src/capability.rs
xai-grok-memory/src/
xai-grok-hooks/src/dispatcher.rs
mcp_dispatcher.rs · mcp_restart.rs
xai-grok-agent/src/plugins/
Every design decision must trace back to a real source branch
// Do not grant trust if plugin root cannot be canonicalized
match dunce::canonicalize(plugin_root) {
Ok(canonical) => self.trusted.contains(&canonical),
Err(_) => false,
}Your design must also specify failure defaults. When policy cannot be read, tool results cannot be parsed, or a checkpoint cannot be restored — the system should respectively stop, degrade, or prompt the user.
crates/codegen/xai-grok-agent/src/plugins/trust.rs100-Point Review Rubric
Automatic disqualifiers: submission does not identify where sensitive data lands; high-risk tools have no permission path; crash recovery is claimed but untested; source code references cannot be traced to a file path.
Lab: 90-Minute Design Sprint
Final Submission Package
Reviewable design archive
- 15 min: Define users, repo, executable permissions, and success criteria.
- 20 min: Complete the core visual and nine-dimension decision cards; mark all state owners.
- 20 min: Implement one tool contract and a minimal model-to-tool call chain.
- 15 min: Inject timeouts, permission denials, and process crashes; record recovery results.
- 10 min: Complete data flow, redaction, and plugin trust checks.
- 10 min: Self-assess using the rubric; submit 3 ADRs, test records, and a 5-minute demo script.
The maturity of a Coding Agent shows in its boundaries and failure paths. The nine-dimension workbench helps you convert model capabilities into an engineering system that is runnable, recoverable, auditable, and extensible.
Source snapshot note: This page uses the local grok-build-main as its design case library; path anchors come from real source code. The delivery formats in the workbench are course design artifacts and do not claim to be the official architecture template of Grok Build. Students may use other tech stacks, but each decision must be supported by equivalent-quality evidence.
Why “Coding Agent Design Workbench” can find relevant content
“The capstone task evolves from a feature list to a runnable system design.” moves retrieval beyond storing material: the real question is how to find what is relevant. That decision shapes the input quality of RAG, recommendation, and image-search systems.
Similarity is not the answer
In the flow described by “Define the responsibility boundaries of entry points, state ownership, model loops, and external extensions”, embeddings place items in a comparable semantic space and a neighbor index narrows the search. The final answer still depends on whether the retrieved chunks cover the question, whether the distance metric fits, and whether the evidence is current.
- Least-privilege by default
- Every external action is traceable
- Crash recovery is explainable
Separate findable from relevant
Turn “The maturity of a Coding Agent shows in its boundaries and failure paths.” into a small test: prepare queries with known answers, record relevance, misses, and distractors, then decide whether chunking, the index, or reranking needs to change.
From “Coding Agent Design Workbench” to “Complete System Boundaries”
“Coding Agent Design Workbench” grounds the problem in “The capstone task evolves from a feature list to a runnable system design. Make explicit decisions across nine dimensions — each must include a contract, failure path, validation method, and submittable deliver…”. “Complete System Boundaries” then moves it toward “Define the responsibility boundaries of entry points, state ownership, model loops, and external extensions”. Together, they show that the lesson is not just a conclusion to remember, but a claim with conditions.
Carry the judgment into the next situation
The same logic applies to retrieval: define what counts as relevant, check whether recall covers the question, and then inspect whether ranking, chunking, or freshness pushed useful evidence out.
- “Coding Agent Design Workbench”: The capstone task evolves from a feature list to a runnable system design. Make explicit decisions across nine dimensions — each must include a contract, failure path, validation method, and submittable deliver…
- “Complete System Boundaries”: Define the responsibility boundaries of entry points, state ownership, model loops, and external extensions
- “The closing point”: Extension code has a trust boundary
The final “The closing point” brings the discussion to “Extension code has a trust boundary”. The useful thing to carry forward is knowing which judgments must be revisited when input, scale, or risk changes.
I turned one judgment from this article into a small experiment I could run today. Knowing what to observe next is more useful than simply remembering the conclusion.
After reading this, I first looked for the conditions behind the idea instead of copying the method into a project. That order made the later trade-offs much clearer.
When this judgment reaches real work, which constraint should be added first? I am curious which step matters most between reading and the first practical attempt.
No discussion on this article yet.