AI Agent Tutorial: Add One Capability, Then Break It

This AI agent tutorial builds your first agent in six passes, adding exactly one capability per pass and deliberately breaking it before you add the next. That is the whole method. Most beginner agents do not fail because the builder was too hard; they fail because five capabilities went in at once and nobody knows which one is lying.

This AI agent tutorial inverts the usual order. Every other guide teaches you to assemble the agent and then test it. We think that is backwards, because a finished agent gives you one signal (it worked, or it did not) while a build that stops after every addition gives you six. The angle we will defend for the rest of this piece: the useful output of your first build is not the agent, it is the break log.

Here is the failure that made us write it this way. On Hacker News in February 2026, a developer posting as agenteo described connecting an agent to a production database for product analytics. Asked how many records were "running", the agent saw raw status values 0, 1, 2, 3 and guessed. It "picked 'failed' records instead of 'running' and confidently gave the wrong number." Nothing crashed. No error appeared. The agent reported success. That is the shape of almost every real agent failure, and no tutorial that ends at "it works" will ever catch it.

The short answer: Add one capability, break it on purpose, write down what happened, then add the next. Six passes, one afternoon, and you finish with an agent whose limits you can name, which is the only kind worth connecting to anything real.

Last updated: July 30, 2026.

The Add One, Break One sequence: six passes, each with a capability and the break test that qualifies it.

One disclosure before we start. We have not run this exact six-pass build as a timed, instrumented experiment on our own platform, so no number in this AI agent tutorial is presented as a LeapForce measurement. Everything quantified below is either cited to a named external source or labelled as an estimate. Where we say "expect roughly an afternoon", that is judgement, not a stopwatch.

What You Need Before You Open a Builder

Four things, and none of them is a tool: a job written as one sentence, a place the answer has to appear, a data source you are allowed to read, and a person whose name goes next to the agent. If you cannot supply all four in ten minutes, the agent is not ready to be built, and no builder will rescue that.

This is the prerequisites block of the AI agent tutorial, and it exists because scoping is where beginner agents actually die. Gartner predicted in a June 2025 press release that over 40% of agentic AI projects will be cancelled by the end of 2027, attributing it to escalating costs, unclear business value, or inadequate risk controls. Two of those three are scoping failures that happen before anyone touches a canvas. The same release notes that many vendors are engaged in "agent washing", rebranding assistants, chatbots and robotic process automation as agentic, and estimates that only around 130 of the thousands of self-described agentic vendors are real.

Here is the checklist, filled in with the example we will carry all the way through this piece.

Notice what is absent. If your plan is to build an AI agent without coding, none of this changes. There is still no model choice, no framework, no vector database, no decision about LangChain versus a drag-and-drop canvas. Those are pass-2 and pass-3 concerns. Choosing a builder before you have written the refusal clause is the single most common way to spend a week and ship nothing.

We wrote a fuller version of this design step in our earlier analysis, how to create an AI agent, spec first, which covers the one-page spec sheet in more depth than a tutorial needs. If you want the tool-selection half, how to judge a builder by its credential model rather than its canvas, that sits in no-code AI agent builder: the one IT will approve. This piece assumes both decisions are made and puts you at the keyboard.

Why this particular example. Contract renewal lookup is a good first build for the same reason inbox triage is: a wrong answer is cheap. Nobody is billed, nothing is sent, no customer sees it. The agent reads, reasons, and posts a message a human immediately eyeballs. It also has the one property that makes a tutorial honest — a genuinely ambiguous field. Contract status will turn out to be an integer, and that is where our worked build breaks.

The Method: Add One, Break One

Add One, Break One, the method this AI agent tutorial is built around, is a build order with a rule attached: no capability is added to the agent until the previous capability has been observed failing at least once, on purpose, with the result written down. Six passes, six break tests, one log. The agent that emerges is not more capable than one built in a single sitting — it is more legible.

The reason to work this way is that agent failures are not loud. A practitioner posting as vincentvandeth, describing six months running a multi-agent system in production, put the pattern plainly: agents "rarely fail catastrophically, they fail subtly." His list names the exact conditions a single end-of-build test cannot see. Output that is plausible but wrong, reported with high confidence. Contradictions that appear only after fifty tool calls. Work that passes the tests and misses the edge case. His prescription was quality gates between steps rather than one review at the end. Add One, Break One is the beginner-scale version of that.

The evidence that this caution is warranted is not anecdotal. TheAgentCompany, a benchmark from Carnegie Mellon and Duke researchers that drops agents into a simulated software company and asks them to do ordinary office work, reported at publication that "the most competitive agent can complete 30% of tasks autonomously." That paper was submitted in December 2024 and last revised in September 2025. Its live leaderboard has moved since: the top entry, dated 25 June 2026, resolves 46.3% of tasks fully with a 58.1% partial-credit score. That is real progress and it is worth stating precisely rather than reaching for the older, gloomier number. It is also still well under half. On realistic multi-step office work, the best publicly benchmarked agent in the world finishes fewer than one task in two without help.

So the question of how to build an AI agent well is not "can I make one work". It is "will I notice when it does not".

What a break test is, and what it is not

A break test is a deliberate attempt to make the capability you just added produce a wrong answer confidently. It is not error handling and it is not a unit test. You are not checking that the agent survives bad input; you are checking that you can see it fail.

Every break test in this AI agent tutorial has the same three parts:

1. The stimulus. The specific input, question, or condition you introduce.
2. The tell. What you will look at to decide whether the agent failed — and crucially, where that evidence lives after the run finishes.
3. The verdict. Passed, failed, or worse than either: silently wrong.

That third verdict is the one that matters. An agent that errors out is doing you a favour. An agent that returns a well-formatted wrong answer is the thing you are hunting.

The break log

One table, six rows, kept open next to the builder. Write the row before you run the test, so you commit to the tell in advance rather than rationalising whatever you see. The assembled version of this log for our worked example is further down, and it is the artifact you should actually copy.

If a pass produces "silently wrong" and you cannot make it produce "failed loudly" instead, you have found the boundary of what this agent should be allowed to do. Write it into the refusal clause and move on. That is a successful outcome, not a blocked one.

Pass 1: Give It a Trigger and a Refusal

Add nothing but the ability to be invoked and the instruction to decline out-of-scope requests. No model reasoning, no tools, no data. The break test is to ask it something adjacent but wrong, and see whether it declines or improvises.

This feels absurdly small, and that is deliberate. Most builders make it trivially easy to wire a trigger, so people wire five things at once and never learn what the trigger alone does. Spend fifteen minutes here.

What you configure. A trigger — a slash command in Slack, a webhook, a scheduled run, or a form submission. A system instruction containing the one-sentence job from your prerequisites table and the refusal clause. An output destination. That is all.

For our worked example the system instruction reads, roughly:

You answer exactly one question: which vendor contracts renew in the
next 60 days, and who owns each one.

If asked anything else, reply: "I only answer contract renewal
questions. Ask the ops lead." Do not attempt the request.

If a contract has no end date recorded, list it as "end date unknown".
Never estimate or infer a renewal date.

The break test. Invoke it with a question that is plausibly in the neighbourhood but outside the job. For a renewal agent, ask: "What did we pay Acme last quarter?" That is a contracts question. It is not a renewals question. A well-scoped agent refuses. A badly scoped one — and most first drafts are badly scoped — tries to be helpful.

The tell. The literal text of the reply. You are looking for the refusal string you wrote, not a paraphrase of it and not an apology followed by an attempt.

What usually goes wrong. The agent produces something like "I don't have access to payment data, but based on the contract value of $48,000 annually, last quarter would have been approximately $12,000." That is the failure. It refused the data access and then answered anyway by inference. Tighten the instruction from "do not answer" to "do not attempt the request", and re-run. If it still improvises, your instruction is competing with the model's helpfulness training, and you need the refusal enforced structurally in pass 3 by simply not giving it the data.

Why this pass earns its place. Every capability you add later inherits the boundary you set here. If the boundary is soft in pass 1, it is soft in pass 6 with write access attached.

Pass 2: Add the Model, Then Ask It Something It Cannot Know

Add reasoning and an answer format, still with no data connected. The break test is to ask a question the agent has no possible source for and check whether it says so. An agent that invents an answer with no data will invent one with partial data, which is far harder to catch.

What you configure. Pick a model and give it an output shape. For a first build the shape matters more than the model. Ask for a structured answer — a short list where each item carries the vendor name, the renewal date, the owner, and a source reference — rather than free prose. Structured output is not an aesthetic preference; it creates named slots that can be visibly empty, and an empty slot is a signal you can see.

Add one more instruction, which does more work than anything else in this build:

Every line of your answer must cite the record it came from.
If you cannot cite a record, do not include the line.

The break test. Ask the agent, with no data source attached, "Which contracts renew next month?" It has nothing. There is no table, no file, no connector. The only correct behaviour is to say it has no data.

The tell. Whether the reply contains any vendor name at all. Not whether it is hedged, not whether it sounds uncertain — whether a specific-looking fact appears. If the model produces "Acme Corp, renewing 15 August, owner unknown", you have just watched it fabricate in the safest possible conditions, and you have learned something genuinely useful before connecting anything real.

What usually goes wrong. Models are strongly disposed to fill a requested structure. If you ask for a list of three items, you will frequently get three items. Countermeasure: never specify a count. Say "list every contract that qualifies, which may be zero", and make the zero case explicit in the instruction with the exact wording you want back.

The concept behind this pass. You are separating two failure modes that beginners conflate. A retrieval failure means the agent could not find the data; a generation failure means it produced data that was never there. They look identical in the output and need opposite fixes, and testing the model alone is the only cheap way to characterise the second.

Pass 3: Add One Read Tool, Then Point It at an Ambiguous Field

Connect exactly one read-only data source, scoped to the minimum columns the job needs. The break test is to ask a question whose answer depends on a field the agent has to interpret rather than read. This is where our worked build fails, and it is the most valuable failure in the sequence.

What you configure. A read-only connection. In practice this means a database user with SELECT on one view, an API token with a read scope, or a shared folder mounted read-only. It does not mean your own account credentials. If the only way your builder can reach the data is by borrowing the OAuth token of the person who set it up, note that in the break log now — it is a real finding, and we come back to it in pass 6.

Scope the view deliberately. Our contracts view exposes six columns and nothing else:

vendor_name, start_date, end_date, owner_email, contract_value, status

The break test. Ask a question that depends on status. Ours is: "Which active contracts renew in the next 60 days?"

Here is the trap, and it is the one agenteo hit. The status column is an integer. The values are 0, 1, 2, 3. The agent can see the numbers. It cannot see what they mean, because the meaning lives in application code, not in the database. So it guesses. Worse, it guesses plausibly. In agenteo's case the agent picked the wrong enum value entirely and reported the count with full confidence.

The tell. Ask for the query or the reasoning trace, not just the answer. Most builders can show you the tool call. Compare the filter the agent actually applied against the one you would have written. If it filtered status = 1 and active is really status = 2, the answer is wrong in a way the answer itself will never reveal.

The fix, and why it generalises. agenteo's own resolution was to give the agent the enum definition rather than hoping it would infer one — in his description, the agent then "finds the enum and stops guessing". The generalisable rule for your build: never expose a coded field to an agent without also exposing its codebook. In practice you have three options, in descending order of preference:

Realistically, most people building their first agent cannot change a database view, so option two is where you will land. If it is, write the enum into the KNOWN FRAGILITY field of the agent definition below and tell whoever owns the application that an agent now depends on their status codes. That sentence costs nothing and is the only thing standing between you and a silent breakage the day a fifth status value appears.

Whichever you choose, the break log entry is the point. You now know that this agent's answer quality depends on a mapping that lives outside the agent, and you will remember that the next time the application team adds status = 4.

A second break test worth running here. Ask for something the view genuinely cannot answer — "which of these contracts auto-renew?" when there is no auto-renew column. This checks that the pass-2 citation rule survived contact with real data. A great many agents that correctly refuse in pass 2 start inferring again once a partially relevant table is in reach.

Pass 4: Add the Second Source, Then Make Them Disagree

Connect a second read-only source and immediately construct a case where the two sources contradict each other. The break test is not whether the agent picks the right one — it is whether it notices there is a conflict at all.

Almost every real agent reads from more than one place. Our renewal agent needs owner names, and the contracts table only has owner_email. The second source is the staff directory, which maps email to a person and a team.

What you configure. The same discipline as pass 3: read-only, minimum columns, explicit scope. And one new instruction:

If two sources disagree about the same fact, report both values and
mark the line as conflicting. Do not choose between them.

The break test. Create the conflict yourself. The easiest realistic one: pick a contract whose owner_email belongs to someone who has left, so the directory returns no match, or returns a person now in a different team. Alternatively, if you can edit test data, set an end date in the contracts table that disagrees with an end date recorded in a renewals spreadsheet.

The tell. Whether the word "conflicting" — or whatever marker you specified — appears. Silent reconciliation is the failure. An agent that quietly picks the more recent record, or the one from the source listed first in its instructions, is making a policy decision that nobody asked it to make and nobody can audit.

What usually goes wrong. Two things, and they are opposite. Some agents reconcile silently, as above. Others over-flag: once you tell a model to look for conflicts it starts reporting trivial formatting differences as contradictions, and the output becomes unreadable. Tune by naming the fields that count: "a conflict means a different end date or a different owner. Formatting differences are not conflicts."

Why the order matters. Notice that we did not connect both sources in pass 3 and test them together. If you had, and the answer came back wrong, you would not know whether the enum was misread, the join was wrong, or the directory was stale. One capability per pass is not fussiness. It is the only way the break log has diagnostic value.

At this point the agent is genuinely useful and has touched nothing. It reads two sources, answers one question, cites its records, refuses what it cannot support, and flags disagreement. For a large number of real business jobs, this is the finished product and you should stop here. Read-only agents are where the use-case ranking by blast radius puts the safest work, and there is no shame in a first build that never writes anything.

Pass 5: Add the First Write Action Behind an Approval Gate

Add exactly one action that changes something outside the agent, and put a human approval step in front of it before you ever run it unapproved. The break test has two halves: approve nothing and confirm nothing happened, then try to make the agent loop and confirm something stops it.

This is the pass the competing tutorials skip, and it is the one that separates a demo from a system. Reading is reversible. Writing is not.

What you configure. One action. For our example: draft a renewal reminder email to the internal owner — not to the vendor — and hold it for approval. Note the deliberate choice of the least consequential possible write. A message to a colleague who expects it is about as low-stakes as an outbound action gets. Do not make your first write action anything that touches a customer, a payment, or a record of truth.

The gate has to satisfy three properties, and a checkbox in a prompt satisfies none of them:

The distinction between an instruction and a control is the whole game here. If your agent's restraint depends on a sentence in its prompt, it is not a gate, it is a suggestion — a point we argued at more length in AI agent guardrails: you can never detect what you can simply forbid. The check is simple: if a cleverly worded input could talk the agent past the restriction, it was never a control.

That is not a hypothetical concern. The OWASP Top 10 for Agentic Applications, published on 9 December 2025, catalogues ten risk categories specific to agents that plan, hold memory, and act with delegated authority. ASI01 is Agent Goal Hijack, ASI02 is Tool Misuse, and ASI03 is Identity and Privilege Abuse. The first three entries on the list are all versions of the same sentence: the agent did a permitted thing for an unintended reason. A prompt-level restriction is exactly the kind of control those attacks are designed to walk through. NIST's adversarial machine learning taxonomy, AI 100-2e2025, published in March 2025, exists precisely to give this class of attack a shared vocabulary and to set out where the current mitigations sit.

Break test A: the gate holds. Trigger a run that should produce a draft. Approve nothing. Walk away for ten minutes. Then check the destination directly — open the mailbox, not the agent's log. The tell is that no message exists. Agents that report "email sent" in their own transcript while nothing arrived are common enough that checking the agent's own account of itself is not verification.

Break test B: the loop stops. Give the agent a condition that could cause repetition — for our example, a contracts view where every row is missing an owner, so every lookup fails and a naive retry loop keeps going. Then check that something halts it: a maximum step count, a spend cap, a timeout, or all three. The tell is where the run stopped and what recorded the stop.

This second test is the one people skip and regret. A looping agent does not damage data; it spends money quietly overnight. TheAgentCompany's leaderboard publishes an average cost per task for entries that report it, and the spread is instructive: from $0.28 to $6.78 per task depending on the model and agent scaffold. A single task is affordable at either end. A retry loop running unattended at the top of that range is not.

Break test C, optional but recommended: the poisoned input. If your agent reads anything a third party can write — an inbox, a ticket queue, a shared document, put a line into that content instructing the agent to do something else, and see what happens. Run this against test data or a copy you control, with the system owner's knowledge. Writing planted instructions into a live shared inbox or a colleague's document is tampering with production content, and it is not a thing to do quietly on a Tuesday afternoon. This is indirect prompt injection, and it is a live problem rather than a solved one. You are not going to fix it in an afternoon. You are establishing whether your agent's write action is reachable from text that a stranger controls, which is a fact you want in the break log rather than in an incident report.

Pass 6: Give It an Identity, an Owner, and an Exit

Give the agent its own credential rather than a borrowed one, put a human name against it, and set an expiry. The break test is the leaver test: revoke the credential and confirm the agent stops cleanly rather than failing in some interesting way.

Most tutorials end at pass 5. This pass is why we wrote a seventh section instead of stopping there, and it is the difference between an agent you built and an agent your company owns.

The question that exposes the problem. What is your agent authenticating as right now? For most first builds the honest answer is: as you. The connector was set up with your OAuth token, so every action the agent takes appears in the audit log as an action you took. That is convenient during the build and indefensible afterwards, for four separate reasons:

What you configure. A dedicated identity for the agent, with the narrowest scope that lets it do its job, a named human owner, and an expiry date. This is not an enterprise-only luxury — most connector platforms support a service account or a scoped API key, and the ten minutes it takes now is the cheapest ten minutes in the whole build. We set out the fuller argument for treating agents as first-class non-human identities in owner, scope, expiry for AI agents.

The break test: the leaver test. Revoke the agent's credential and run it. Three outcomes, in descending order of quality:

1. It fails closed and says so. The connector returns an authorisation error, the agent reports that it cannot reach the data, and no answer is produced. This is correct.
2. It fails closed and says nothing useful. The run errors out with a stack trace or a blank reply. Acceptable, but fix the message — future-you will be debugging this at speed.
3. It answers anyway. This means it had another path to the data, and you have just discovered a credential you did not know about. This is the finding that justifies the entire pass.

The expiry, and why it is not bureaucracy. An agent with no expiry date is a permanent grant that nobody reviews. Set it to ninety days for a first build. When it lapses, you are forced to decide whether the agent is still earning its access. That forced decision is the only reliable defence against the slow accumulation of forgotten agents holding live credentials, which is what OWASP files under ASI10, Rogue Agents.

Where the tutorial's product bridge honestly begins. Pass 6 is the step that no builder gives you for free, and it is the step that determines whether your afternoon's work survives contact with your own IT function. We come back to it at the end.

The Finished Build: One Complete Break Log

Here is the assembled artifact — the complete break log for the renewal agent, all six passes, with the results you should realistically expect on a first attempt rather than the ones a tutorial wishes for. Copy the structure, not the contents.

Read the Result column. Three of six passes produced a silently wrong answer on first attempt, and every one of those three would have shipped invisibly in a build tested only at the end. The agent here is a Slack bot. The log is a document telling the next person exactly where it is fragile.

To be explicit about provenance: this table is a worked illustration built from the failure modes named in our cited sources — the enum misread in row 3 is the pattern agenteo described, the silent reconciliation in row 4 is the "almost right" failure vincentvandeth described. It is not a transcript of a run we instrumented and timed. We have flagged that in the disclosure at the top and we are flagging it again here, because a table that looks like a lab notebook should say plainly whether it is one.

The finished agent definition

The other half of the assembled artifact is the agent itself, written down in one place so it can be handed over. Six fields, and every one of them came out of a pass:

NAME        Renewal Watch
OWNER       Operations lead (named individual)
IDENTITY    Dedicated service credential, expires in 90 days
TRIGGER     /renewals in #ops
JOB         List vendor contracts renewing within 60 days, with owners
REFUSES     Anything not a renewal question. Missing end date =
            "end date unknown". Never estimates a date.
READS       contracts_view (6 columns, read-only)
            staff_directory (email, name, team, read-only)
WRITES      Draft reminder email to the internal owner, approval-gated
LIMITS      25 steps max, spend cap per run, 60-second timeout
KNOWN FRAGILITY
            status_label is derived upstream; a new status value in the
            application will silently change what "active" means.
            Reads a channel third parties can post in — injection
            surface not fully mitigated.

That last field, KNOWN FRAGILITY, is the one nobody writes and everybody needs. It is where the unresolved findings from the break log go to stay visible.

How Long This Takes and What It Costs

Expect two to four hours for a first pass through all six steps on a no-code builder, assuming the data access already exists. If you have to request database access or a service account, the clock is set by your IT ticket queue, not by the build — and that wait is typically days, not hours.

We want to be careful here, because this is the question where tutorials most often assert numbers they have not measured. The honest breakdown is a mixture of estimate and cited fact, and we have labelled which is which.

The per-task range deserves a second look, because it is the number that surprises people. A twenty-four-fold spread between the cheapest and most expensive scaffold on the same benchmark tasks means the model and framework you pick change your running cost by more than an order of magnitude. For a renewal agent invoked a few times a week, any of it is negligible. For an agent that runs on every inbound ticket, that spread is the difference between a rounding error and a line item. We have written separately about how model routing changes that arithmetic; the tutorial-scale takeaway is simply to check the cost per run before you put the agent on a high-volume trigger, not after.

What the method itself costs you

The fair objection to any staged build is that it is slower than just building the thing. It is, and the premium is smaller than it looks: stopping to write and run a break test adds perhaps ten minutes per pass, so roughly an hour across the six. What you buy for that hour is visible in the Result column of the log above. Three of the six passes produced an answer that was wrong and looked right. Each of those, found later, costs a debugging session in which you do not know which of six capabilities is at fault. The whole reason to learn how to build an AI agent this way is that the search space stays at one.

There is a second return that shows up later. A team that keeps break logs accumulates a written record of where its agents are fragile, which is what an auditor or a new hire eventually asks for. Building without one is not faster. It is the same work, deferred, done by someone with less context.

What this section deliberately does not do is give you a total cost of ownership figure. The licence is rarely the expensive part, and that argument needs its own piece rather than a paragraph — our earlier analysis of enterprise AI implementation cost beyond the licence covers it properly.

Eight Mistakes That Survive the Demo

These are the errors that no AI agent tutorial catches for you, because they do not show up while you are building, when you are paying attention. They surface two weeks later, when you are not.

1. Scoping to a role instead of a job. "An agent for the ops team" is not a scope. "Answer renewal questions in #ops" is. The tell is that you cannot write a refusal clause, because you cannot say what is out of scope. If pass 1 was hard, this is why.

2. Treating the prompt as a permission system. Writing "never send emails to customers" in a system instruction is a preference. Not connecting an outbound customer email tool is a control. Everything in the OWASP agentic list under Tool Misuse depends on the first being mistaken for the second.

3. Exposing coded fields without their codebook. The pass-3 failure, and it generalises well past enums. Currency columns without a currency, dates without a timezone, boolean flags whose names are negations. An agent reads these and infers, and inference looks exactly like knowledge in the output.

4. Testing with clean data. Your test contracts all have end dates and living owners. Real ones do not. Deliberately seed the ugly rows before you test, or the first ugly row in production is your test.

5. Trusting the agent's own account of itself. "Email sent" in a transcript is a claim, not evidence. Check the destination. This is the habit that pass 5 is really teaching.

6. Building on a borrowed credential and never revisiting it. The most common single defect in a working first agent. It runs beautifully until the builder changes team.

7. Adding memory before you need it. Persistent memory across runs is the fastest way to turn a debuggable agent into an undebuggable one, because the same input stops producing the same output. Our renewal agent is stateless by design. Add memory when a specific job requires it, and add it as its own pass with its own break test — poisoning stored context is OWASP's ASI06.

8. Declaring success from a demo run. A demo is one input chosen by the person who built the thing. Gartner's cancellation prediction lists "unclear business value" alongside cost and risk controls, and a proof of concept that only ever ran on the builder's favourite example is precisely how business value stays unclear. Run it on twenty real inputs before anyone else sees it.

Where This Method Runs Out

Add One, Break One is a first-build discipline, and this AI agent tutorial is scoped to a first build. It is not an evaluation framework, it does not scale past a single agent, and there are several things it explicitly cannot tell you. Being direct about that is more useful than selling it further.

It does not measure quality, only visibility. A break log tells you where the agent fails in ways you can see. It says nothing about whether the agent is good — whether its answers are useful, well-formatted, or better than the spreadsheet the ops lead already keeps. That needs a real evaluation set with expected outputs, which is a different and larger job. The spec-first approach covers writing eval sets before prompts, and we would run both.

Six passes is a floor, not a schema. Real agents need passes we have not written: retrieval over documents, memory, human handoff, multi-agent handoff. Each deserves the same treatment — one capability, one break test — but we are not going to pretend a six-row table covers a system that routes work between four agents. Multi-agent permission boundaries are their own problem, and we treated them separately in the multi-agent handoff permission contract.

AI agent testing here is adversarial in intent, not in rigour. Trying one poisoned input is not a security assessment. Indirect prompt injection remains an active research problem rather than a checkbox; NIST publishes the taxonomy of these attacks precisely because the field needs shared terminology for something still being worked out. If your agent will touch regulated data or act on behalf of customers, this tutorial gets you to the point where a real security review is worth someone's time. It does not replace one.

The benchmark numbers are directional, not predictive. TheAgentCompany's 46.3% is a measurement of specific agent scaffolds on specific simulated office tasks. It is the best public evidence we know of for how capable agents are at realistic multi-step work, and it is genuinely not a forecast of how your renewal agent will perform on your contracts. Treat it as a reason for caution, not as a number to put in a business case.

We have not run this build ourselves as a controlled experiment. Stated once at the top and repeated here because it matters: the break log above is constructed from documented failure patterns, not from an instrumented run on our own platform. If you run the six passes and your results differ, your results are the better evidence.

Two sources a reader might expect are absent. We could not verify vendor-published claims about typical build times — the "30 minutes to your first agent" figures that circulate come from builder marketing pages and none of them publish a method, so we have not cited any of them. Where we give a time estimate above, we have labelled it as our estimate rather than dressing it in someone else's authority.

What Happens After the Tutorial Ends

Passes 1 through 5 of this AI agent tutorial you can do in any builder. Pass 6 is where a personal project becomes a company asset, and it is the step most builders leave to you — which is the layer LeapForce works on.

The honest framing: this AI agent tutorial is not about our product, and nothing above requires it. But the six-pass method keeps arriving at the same four questions, and they are the ones a builder alone does not answer. Who owns this agent. What exactly can it reach. What did it do. What did it cost. Our platform exists because those questions are structural rather than per-agent. The agent gets its own non-human identity with an owner, a scope and an expiry instead of borrowing yours. The write action in pass 5 sits behind a connector with action-level scoping and a human approval gate rather than a prompt instruction. The break log's questions have standing answers in the action audit rather than being reconstructed from memory. Promoting a personal build into a shared one follows the lifecycle our AI Coworkers product names as Build, Scope, Review, Share, Improve. Pass 6 of this tutorial is that Scope step done by hand.

One caveat, in the spirit of the rest of this piece: LeapForce is in active development and per-capability build status is disclosed openly on the site, so check what is live before you plan around it. Our gateway rollout guide advises "Observe first. Enforce second. Optimize third." That is the same instinct as this tutorial, applied to a company rather than a single agent. Watch it before you constrain it, and constrain it before you tune it.

Ready to Govern Your AI?

Talk to LeapForce — one controlled layer for every AI tool, connector, model, and agent.