One valid build order, with the reason for every position
This is a sequence in which every module's prerequisites already exist. Other valid sequences exist. Modules with no dependency between them can swap places, and any module can be built early if you stub what it needs.
Inference engineeringfull lesson
Serve models on fixed hardware and know what each second costs.
Starting point. Needs nothing else.
Knowledge managementoutline
Collect, validate, name, tier, and retire documents before any index sees them.
Starting point. Needs nothing else.
API and gatewayoutline
One contract for every caller, with keys, scopes, limits, and a single public door.
- After Inference engineeringA gateway forwards to an engine. Its timeouts and limits are set from measured load times and generation rates.
State and storageoutline
Where facts live between calls, who may write them, and how concurrent writers stay safe.
Starting point. Needs nothing else.
RAG and knowledge graphfull lesson
Find the right passage, prove it, and add graph edges where vectors miss.
- After Inference engineeringSearch needs an embedding model at query time and at index time. The vector column width is fixed by that model, so the model choice comes first.
- After Knowledge managementRetrieval can only return what was ingested, and it ranks by signals created at ingestion: chunk boundaries, source paths, authority tiers. Curation mistakes become retrieval mistakes that no ranking fix removes.
- After State and storageChunks, vectors, the file ledger, and graph edges need a store that survives concurrent readers and a nightly writer. The reference build lost weeks to single-writer stores before moving to Postgres.
Tools and MCPoutline
Give the model typed actions, and serve them over a protocol any harness can call.
- After API and gatewayTool calling rides on the chat contract: tool schemas go in the request and tool calls come back in the response. Key scope decides who gets tools.
Harness engineeringfull lesson
The loop around the model: prompt assembly, tool execution, budgets, checks, logs.
- After API and gatewayThe harness sits behind the gateway contract. Keys carry scopes, and the harness reads the scope to decide whether a caller gets tools at all.
- After Inference engineeringThe planner is a model call. Round budgets, output caps, and prompt size limits are set from measured inference numbers.
- After State and storageThe loop is a state machine. Concurrent tool results have to merge into one conversation without overwriting each other, so the merge rules are defined before the loop that relies on them.
- After Tools and MCPA loop with no tools is a chat proxy. You need at least one registered tool with a schema to exercise the tool path.
Evaluationfull lesson
Sealed test sets, layered metrics, and enough repeats to trust a difference.
- After RAG and knowledge graphThe retrieval eval calls the search tool and scores what it returns. Gold questions are generated from indexed chunks, so the index has to exist.
- After Harness engineeringEnd-to-end evals send requests through the agent and read its logs. The log formats are defined by the harness.
- After Knowledge managementHeld-out material is selected from the corpus. You cannot seal chunks that have not been ingested.
Guardrails and verificationoutline
Deterministic checks on tool calls and on answers, each one written from a real failure.
- After Harness engineeringThe guard is a stage in the loop: after the draft, before the response. Hooks wrap tool execution. Both need the loop.
- After Tools and MCPThe guard compares the answer with tool results. Tools must return structured values the guard can parse.
Memoryoutline
What the agent keeps about a user and about its own past work, and how it gets back into the prompt.
- After Harness engineeringMemory is read at prompt composition and written after the response. Both are harness stages.
- After State and storageMemory is durable state with concurrent writers: live chats and background jobs. It needs the storage guarantees from the state module.
Skillsoutline
Instruction files loaded on demand, so routing knowledge costs nothing until it is needed.
- After Harness engineeringA skill is text injected during prompt composition. Without the composition step there is nowhere to load it.
Multi-agent patternsoutline
Several model roles with separate context, tools, and budgets, coordinated by code.
- After Harness engineeringA sub-agent is a harness loop run as a node. You need one working loop before you can run several.
- After SkillsRoles are defined by scoped instructions. Skills are the mechanism for scoping them.
- After EvaluationEvery added agent adds cost and latency. Only an eval can show that a split improved results.
Operations and deploymentoutline
Supervision, scheduling, logs, backups, and recovery, so the system runs when nobody is watching.
- After Inference engineeringThe engine is the first service to supervise, and its memory limits decide what can run at the same time.
- After Harness engineeringThe agent server is the main service. Its health endpoint and busy marker are what the supervisor and scheduler read.
- After EvaluationScheduled evals and the daily report are how you learn that a deploy made things worse.
SDKs and frameworksoutline
What agent SDKs give you, mapped onto parts you have already built by hand.
- After Harness engineeringYou evaluate an SDK by comparing it with a loop you understand. Without that, every framework's defaults look like requirements.
- After Tools and MCPTools are the part you carry between SDKs. Having them as MCP servers makes the comparison a configuration change.
Self-evolving agentsoutline
A scheduled loop that studies sources and its own logs, promotes what is corroborated, and is graded on sealed tests.
- After EvaluationA loop optimizes what it can measure. Sealed evals have to exist before the loop runs, or it grades itself.
- After MemoryLearned claims and rules are a form of memory. They use the same store, status fields, and recall path.
- After Guardrails and verificationPromotion gates and claim verification are guard logic applied to stored knowledge.
- After RAG and knowledge graphThe learner reads indexed chunks and writes claims that point back to passages.