Perceive · Decide · Act
What an agent is + your first build
The one difference between a chatbot and an agent, then build one that does a real job
A chatbot answers questions. An agent does things. You will learn the perceive-decide-act loop that every agent runs, then build your first agent inside a Claude Project: one job, persistent instructions, repeatable output. The agent you build here is the foundation for every lesson that follows.
Worth knowing:Your first agent is not code. It is a set of persistent instructions inside a Claude Project. Every conversation in that Project follows the rules automatically.
Anyone curious about AI agents but unsure where to startPeople who use Claude for chat but want it to do real workNon-developers who hear 'agent' and think it requires coding
Start Module 1 →Tools · Real input · The result
Tools + the end-to-end win
Give your agent eyes and hands, then run a complete real job from start to finish
Without tools, your agent is stuck in a text box. With tools (web search, file reading, connectors), it can act on your real information. You will learn how an agent decides when to reach for a tool, then run your agent on a full batch of real input and walk away with output you would actually use. This is the proof that the pattern works.
Worth knowing:Each tool you add multiplies what the agent can do. One tool makes it a researcher. Two make it an analyst. Three make it an operator. The tools are the multiplier.
Anyone with a working first agent from Module 1People tired of copy-pasting between Claude and their appsAnyone who wants a repeatable workflow, not a one-shot demo
Start Module 2 →Call gate · Scope · Proof
Tool decisions + tool contracts
Teach the agent when to call a tool, then define what that tool is allowed to do
Tools are useful only when the agent knows when to reach for them. Module 3 gives you the call gate, then turns each future connector into a short contract: read scope, write scope, approval rule, proof rule. The mechanics stay in the L7 lessons. This module gives you the operating judgment before setup.
Worth knowing:The important tool decision happens before the tool call. A good agent names the missing gap, calls the smallest useful tool, and pauses before real changes.
People whose agents guess when they should verifyOperators who need approval gates before agents touch real toolsAnyone preparing for MCP without wanting setup yet
Start Module 3 →Module 4
2 lessons · premiumRemember · Update · Forget
Agent memory
Give the agent a small working note so the next run starts smarter than the last one
Memory is not a transcript. It is the small set of stable facts, approved decisions, and recurring exceptions that improve future runs. Module 4 separates short task state from long memory, then adds the maintenance loop that keeps the note current.
Worth knowing:The best memory note gets shorter over time. ADD, CHANGE, and REMOVE keep old facts from steering new work.
Anyone whose agent keeps relearning the same preferencePeople building repeated weekly or daily agent workflowsTeams that need memory without carrying every transcript forward
Start Module 4 →Module 5
1 lesson · premiumJob · Capability · Boundary
MCP capability mapping
Map what your agent needs MCP for before you wire a single connector
MCP removes copy-paste from the agent loop, but only after you define the job and the exact capabilities. This applied bridge maps one agent job to read scope, write scope, approval, proof, and the existing setup lessons that own the mechanics.
Worth knowing:Start from the capability, not the app. Your agent does not need Slack. It needs a narrow action like drafting a post for approval.
People ready to connect agents to real systemsAnyone who needs MCP explained without setup steps repeatedOperators who need proof before connected tools act
Start Module 5 →Module 6
1 lesson · premiumTrigger · Steps · Done check
Agent skills
Turn one repeated agent workflow into a skill brief you can package later
A skill stores repeatable steps the agent can run by name. Module 6 stops at the brief and cross-links the actual packaging mechanics to l7-03. You decide what deserves to become a skill, what stays in memory, and what belongs in the tool contract.
Worth knowing:Package the repeatable sequence, not the whole agent. Memory says what it knows. Tools say what it can reach. Skills say how to run the job.
People repeating the same agent prompt every weekTeams turning stable workflows into named operating assetsAnyone ready for l7-03 but wanting the brief first
Start Module 6 →Module 7
2 lessons · premiumState · Action · Proof
Rendering UI for agents
Decide when chat is not enough, then design the review screen around the agent
Some agent jobs need more than a chat thread. Module 7 teaches the UI threshold, then turns the agent's work into a small dashboard that separates state, proposed action, proof, and approval. Claude Design and Claude Code own the build mechanics. This module owns the agent UI decision.
Worth knowing:The first interface should usually be one review screen with sample data. Prove the human can understand the run before connecting real writes.
People whose agent output has become too long to review in chatBuilders who need a visible approval surface before adding real actionsTeams that want proof beside the recommendation, not hidden in a thread
Start Module 7 →Module 8
3 lessons · premiumSpecialists · Handoffs · Orchestrator
Multi-agent teams
Split complex work into specialists without creating coordination chaos
A team helps only when the split makes work easier to inspect. Module 8 teaches when one agent should become specialists, how to write the handoff packet between them, and how an orchestrator keeps the run from drifting.
Worth knowing:A two-agent team can be enough. The win is not more agents. The win is clearer review.
People whose single agent is now researching, drafting, reviewing, and reportingOperators building chains where one specialist feeds anotherAnyone tempted to add agents before the handoffs are clear
Start Module 8 →Module 9
2 lessons · premiumGates · Approval · Log
Trust and governance
Place checkpoints before real-world action and leave a record after every run
Teams can pass small errors downstream until they arrive polished. Module 9 adds trust gates before action and a governance log after each run, so you know who approved, what proof was used, what changed, and how to recover.
Worth knowing:A gate after the action is not a gate. It is an audit. Put the checkpoint before the consequence.
Teams letting agents draft, post, update, or escalate workManagers who need approval rules before autonomy expandsAnyone who wants to know why an agent did something three days later
Start Module 9 →Module 10
2 lessons · premiumReview · Test · Build route
Self-improving agents
Let the system improve from evidence, then choose the smallest build path that fits
Self-improvement is supervised, not silent. Module 10 teaches the improvement loop, then closes the track with a route decision: stay no-code, ask Claude Code or Antigravity for a custom build, or request an agent build kit when state, logs, tests, retries, and recovery become part of the job.
Worth knowing:The agent proposes one small evidence-backed change. You decide what becomes permanent.
People ready to improve agents from run evidence instead of one-off chat fixesBuilders deciding when no-code is enough and when a custom build is worth itTeams that need logs, tests, retries, and recovery before autonomy expands
Start Module 10 →