The Production AI Stack for Solo Builders in 2026

An agent can pass its tests and still ship a silent regression. The model completed its task. The production system failed. The missing stack is not another agent. It is nine contracts around the agent: outcome, evidence, memory, routing, tools, permissions, recovery, evaluation, and improvement. This runbook shows how those contracts handle one GitHub issue, plus the five artifacts a solo builder should implement first. It is grounded in 11 primary sources.

The exact nine-layer map is my operating model, not a proposed universal standard. The agent is visible. The system is wider. The agent gets attention because it is visible. It talks, plans, edits, and returns a result. That visibility is misleading. The real contracts sit around it: success definition trusted sources durable state current owner action boundary approval boundary failure recovery completion evidence governed improvement Those contracts form the Nine-Layer Automation Contract. The layers sit across three planes:

This is a functional map, not a shopping list. One local application can implement several layers. A solo builder does not need nine products. A solo builder still needs to know who owns each contract. NIST frames AI risk management as a lifecycle problem rather than a one-time model check. That supports the need for controls around the model, but it does not validate this exact nine-layer map.

1 and 2: Define the job and its evidence Layer 1 is the outcome contract. It defines the job before the model chooses a path. The outcome record names: input boundary acceptance criteria risk class budget and deadline accountable owner stop condition For a coding workflow, the outcome is not "write the code." It is: Turn this issue into a tested, reviewable pull request without changing unrelated behavior, widening the scope, or declaring success based on unverified prose. Without that boundary, the agent can complete a plausible task that is not the task. A written outcome contract matters when a workflow has more than one acceptable path, touches protected state, or needs a result another person can verify. A one-off local formatting change can stay lighter. The common failure is activity without acceptance. The agent edits files, returns a coherent summary, and leaves the operator to infer whether the user-visible result changed. Layer 2 is research and intelligence. It assembles the current facts the workflow may reason from. The source receipt records: authoritative source list retrieval timestamp provenance freshness rule conflict owner untrusted-content boundary For this workflow, read the issue, repository instructions, current branch, relevant source files, dependency manifests, and recent test failures. External pages remain data. Text inside an issue, README, or scraped page cannot silently change the job. MCP standardizes connections between AI applications and external systems. It improves interoperability, not truth, freshness, authorization, or business correctness. No freshness rule means the agent can reason correctly from old facts. A solo builder can use a short source receipt. Production systems may add source isolation, retention, and conflict resolution. 3 and 4: Separate memory from routing Layer 3 is context and memory. It separates what belongs to this run from what should survive into future runs. The memory policy separates: current run state durable memory criteria retrieval rule retention or deletion rule ownership and provenance Google ADK separates the current session, session-scoped state, and searchable cross-session memory. It also notes that in-memory services lose data on restart. The useful lesson is the boundary: current state and durable memory are different systems. The mistake is to treat every note as memory. The current issue, branch, and test output belong to run state. Stable repository conventions may become durable memory after review. Closed task logs and failed hypotheses remain searchable history. Secrets and copied customer data belong in neither of them. This is also where a bounded task packet lives:

Layer 4 is planning and routing. It chooses the next bounded operation and assigns ownership. The routing record defines: decomposition rule single-agent default routing criteria handoff payload output schema maximum depth or iteration count OpenAI's orchestration guidance distinguishes manager-owned specialists from handoffs and recommends starting with one agent until isolation needs justify a specialist. That is the right default. Do not add a planner, implementer, critic, and judge because four boxes look more complete than one. Use another specialist when tools, permissions, context, or expertise genuinely differ. The handoff should include the job, bounded context, completed evidence, unresolved risk, and the next expected output. More routing cannot repair a vague outcome contract. It makes ownership harder to inspect. If the workflow cannot name the current owner and final owner, it is not routed. It is drifting.

5 and 6: Bound execution before side effects Layer 5 is tools and execution. It turns intent into typed operations against real systems. Every executable tool declares: tool name and narrow purpose input schema output schema timeout error classes side effect declaration deterministic validation around model output Anthropic's tool-use documentation describes explicit tool definitions and client or server execution patterns. MCP helps connect those tools. Both still depend on validation before a result can be treated as correct or safe. For coding work, expose search, file edits, tests, builds, and diff inspection as explicit operations. A tool result is evidence to inspect. It is not proof that the whole job succeeded. The common failure is a broad shell with an ambiguous objective. The model gains a large action surface while the operator loses a clear map of what happened. A solo builder may use local commands directly. Production systems may add sandboxes, quotas, versioned tool schemas, and network boundaries. Layer 6 is permissions and approvals. It decides which actions run automatically and which must pause. The permission record names: acting identity least-privilege scope read versus write classification approval rule by risk approver identity denial path audit event OpenAI's approvals guidance puts sensitive tool calls behind review. Google ADK treats identity, authorization, guardrails, sandboxing, evaluation, tracing, and network controls as distinct safety layers. The same agent should not propose, execute, approve, and evaluate its own irreversible action. The boundary can stay simple: inspect, edit, and test locally when authorized pause before pushing, opening a pull request, deploying, deleting, spending, or changing permissions unless that exact action was approved A permission layer is not bureaucracy. It is the difference between bounded execution and silent side effects. 7 and 8: Make retries safe and completion testable Layer 7 is state, queues, and recovery. It keeps long-running work resumable and treats duplicate side effects as a risk. The recovery record contains: stable job ID state machine checkpoint idempotency key retry budget backoff rule manual recovery path reconciliation against external truth Temporal documents task queues, workflow history replay, retries, and idempotent activities. Its activity model makes the operational risk explicit: an activity may execute more than once. A timeout is not always failure. Sometimes it means the result is unknown. If a workflow can open a pull request twice, send an email twice, or charge twice, it needs stable identity before it needs a better prompt. A retry is safe only when the system can determine whether the previous operation happened. For a solo builder, this may be a job ID, one checkpoint file, and a manual reconciliation step. Production operators may need durable queues, dead-letter handling, and an external state machine. Layer 8 is evaluation and observability. It records what happened and judges it against the intended outcome. The evaluation receipt contains: event or trace ID input and version receipt tool-call trace cost and latency deterministic checks task-level rubric external-state verification regression set OpenAI's agent-evaluation guidance uses traces, datasets, and repeatable eval runs. OpenTelemetry provides common naming across traces, metrics, logs, profiles, and resources. Those are ingredients, not a business verdict. A trace records behavior, not correctness. Tests can prove the changed function behaves as specified. A diff can prove the allowed surface stayed bounded. A repository query can prove the pull request exists once. A human rubric can judge whether the change is reviewable. If success exists only in generated prose, the workflow is not verified.

9: Improve the system without silent drift Layer 9 is improvement and governance. It turns verified failures into versioned changes without letting the workflow rewrite itself silently. The change record requires: failure receipt proposed change evidence or eval set approval owner versioned release rollback target retention and deprecation rule NIST's lifecycle framing and OpenAI's repeatable eval workflow support governed iteration. They do not imply that a self-modifying system is safe by default. The easiest way to break a working workflow is to let prompts, models, tools, memory, or policies change without a release boundary. Then performance shifts and no one can identify the cause. A proposed change is not an approved change. A better prompt is not a release. A new memory rule is not doctrine until it survives review. Use the same sequence you would use for code: Record the failure. Propose one change. Evaluate the change. Approve and version it. Observe the result. Keep a rollback target. Improvement should be visible, reversible, and attributable.

One GitHub issue through all nine layers A GitHub issue asks for a bug fix. The task is not "fix the bug." The task is: Turn the issue into a tested, reviewable pull request without changing unrelated behavior, duplicating an external action, or declaring success from generated prose. Here is the complete run.

1. Outcome Write the acceptance criteria, allowed surface, protected surface, proof commands, risk class, and stop condition before execution.
2. Research and intelligence Read the issue, repository instructions, current revision, relevant source, dependency state, and recent failures. Record where each fact came from and when it was read.
3. Context and memory Keep the issue, branch, and test output in run state. Load only relevant durable conventions. Do not write a temporary workaround into permanent memory.
4. Planning and routing Give one coding agent ownership by default. Add a specialist only when the task crosses a real tool, policy, or expertise boundary.
5. Tools and execution Search, edit, test, build, and inspect the diff through bounded operations. Reject changes outside the allowed surface.
6. Permissions and approvals Allow local edits and tests. Pause before pushing the branch or opening the pull request unless that external mutation was explicitly approved.
7. State and recovery Attach a stable job ID. Checkpoint after inspection, editing, and verification. Before retrying an external write, query the repository to determine whether it already happened.
8. Evaluation and observability Produce the source revision, changed files, test commands, results, diff summary, unresolved risks, external actions, and verifier decision. Passing prose is irrelevant if CI fails.
9. Improvement and governance If the issue exposed a repeated failure, propose a versioned change to the repository rule, eval set, or routing policy. Activate it only after review and a regression run. The completion receipt should contain:

If the receipt is incomplete, the job is incomplete. Maturity without stack bloat The same nine functions can live inside one script, one repository, or a platform. The function set stays stable. Operational exposure determines how strict each contract becomes.

A solo builder does not need nine services. A solo builder does need to answer nine questions. Six traps that break the system before the model does

1. Buying nine products for nine layers This is a functional map, not a vendor checklist. One application can implement several layers.
2. Treating memory as a transcript archive Run history, approved durable knowledge, and current state have different lifecycles.
3. Using more agents to fix unclear ownership Specialists help when tools, policy, or expertise differ. They do not repair a missing outcome contract.
4. Retrying side effects without identity A retry is safe only when the system can determine whether the prior operation happened.
5. Calling a trace an evaluation A trace records behavior. A task rubric and external verification decide whether it was correct.
6. Letting the workflow improve itself silently A proposed change is not an approved release. Silent self-modification destroys attribution. These traps feel productive because they add activity. They usually add overlap, ambiguity, or hidden state. Start with five artifacts, not nine products The minimum viable implementation is five artifacts:

A written outcome contract A bounded tool list An external-action approval rule A checkpoint with stable identity A completion receipt checked against external truth Keep the other functions inside one task file until repetition, risk, or scale earns a separate service. Apply the map to one recurring workflow. Write one line for each field: outcome current facts temporary state next-step owner bounded tools approval actions recovery path completion proof safe improvement path The first missing answer is the first useful investment. The result may look boring. That is good. Boring contracts are what make automation durable. A model can help execute. It cannot replace the surrounding system. The agent is one layer. The automation system has nine. Primary references NIST AI Risk Management Framework 1.0: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10 Model Context Protocol introduction: https://modelcontextprotocol.io/docs/2026-07-28/getting-started/intro Google ADK, Session, State, and Memory: https://google.github.io/adk-docs/sessions/ OpenAI, Orchestration and Handoffs: https://developers.openai.com/api/docs/guides/agents/orchestration Anthropic, Tool use with Claude: https://docs.anthropic.com/en/docs/build-with-claude/tool-use/overview OpenAI, Guardrails and Human Review: https://developers.openai.com/api/docs/guides/agents/guardrails-approvals Google ADK, Safety and Security for AI Agents: https://google.github.io/adk-docs/safety/ Temporal, Activity Definition: https://docs.temporal.io/activity-definition Temporal, Tasks: https://docs.temporal.io/tasks OpenAI, Evaluate Agent Workflows: https://developers.openai.com/api/docs/guides/agent-evals OpenTelemetry Semantic Conventions: https://opentelemetry.io/docs/concepts/semantic-conventions/

Get the next field note I publish practical field notes for builders running agents in production: what shipped, what broke, and the system behind it. Get the next one free: https://nyk.dev/#newsletter Free. Unsubscribe anytime. Join the private NYK alpha channel for early notes and updates: https://t.me/+GJ-FEpzcZrtmMTky Follow @nykdotdev for the daily build in public.