A hands-on half-day for engineering teams
Your agent worked once. Now make it work every time.
Half a day with your engineers, on your stack. They build the harness around a model: tool contracts that hold, context that does not run out at step twelve, and an evaluation that tells them when they have broken it.
Everyone writes code for most of the session. Where a team wants to take it further, the same material extends into multi-day engagements and the longer programme.
The premise
Nobody's agent fails because the prompt was not clever enough
They fail because a tool returned something the model could not interpret, or the context filled up and the agent forgot what it was doing, or nothing in the system could tell the difference between a good run and a bad one.
All three are engineering problems with known solutions. That is what this half-day covers, and it is why most of it is spent in an editor rather than a slide deck.
The half-day
Four parts, and they write code in all of them
Everyone starts from a working repository, so no time goes on setup. By the end each person has an agent with real tools, a context strategy that survives a long task, and an evaluation that fails when the agent does.
01
The harness is the product
A model call is a small part of an agent. The rest is the harness around it: what the agent can see, what it is allowed to do, what happens when a tool fails, and how the loop knows to stop. We start by taking a working agent apart to see how little of it is prompt.
02
Tools, and the contracts they need
Why tool descriptions are an interface design problem, what a good error message from a tool looks like to a model, and how to shape return values so the agent does not have to guess. Your engineers build tools and watch the agent misuse them until the contracts are right.
03
Context, and what to do when it runs out
Where context actually goes, why long-running agents degrade, and the practical strategies for it: compaction, externalised state, handoff, sub-agents. They take an agent that falls over at step twelve and get it to finish.
04
Knowing whether it works
The part almost everyone skips. Each person writes a small evaluation over their agent, breaks it deliberately, and watches the evaluation catch it. This is the difference between an agent you demo and one you would leave running.
What the team needs
- Your engineers can read and write JavaScript, TypeScript or Python. The examples are in TypeScript; the ideas are not language-specific
- Most of them have called an LLM API at least once, even if only to see it work
- Machines they can install packages on, and an API key for any major model provider
What they do not need
- Any machine learning background. Nothing here involves training a model
- A particular framework. We build the loop directly, then talk about which frameworks are worth adopting and why
- A budget for model calls. The exercises cost a few cents to run
Who teaches it
Tamas Piros
Google Developer Expert in Web Technologies, ambassador for the Agentic AI Foundation, twenty-five years across engineering, developer relations and technical training. 138 talks and workshops delivered in 33 countries, and over a decade of teaching developers.
This half-day is the condensed form of the agent material from the AI Engineering Programme. If your team needs the long form, that is the one to ask about.
Want to see how I teach before any of this? The book is free and online, no sign-up.
Before you commit anything
Read a few hundred pages of it first, free
You do not have to take a workshop on trust. AI Engineering for Web Developers is a complete book, online, with no sign-up and no email gate. It covers the ground this workshop builds on, in the same voice and at the same level of detail.
Alongside it are 200+ technical articles, including worked pieces on agent harnesses, evaluation and MCP. Send your most sceptical engineer at them. If the writing does not convince them, the workshop will not either, and you have lost nothing finding out.
What the workshop adds is the part reading cannot give you: your own engineers building it, on your stack, with someone in the room when it breaks.
If half a day is not enough
The same material, at three lengths
Half a day. The four blocks above, on a prepared repository. The standard version, and the one most teams start with.
Multi-day. The four blocks, then the rest of the time spent applying them to your systems rather than a prepared example. For teams with an agent already in production, or close to it, that is misbehaving in ways they cannot yet explain.
The AI Engineering Programme. Four to six weeks, where agents are one part of a much wider arc: retrieval, structured output, evaluation, security and observability, ending in a capstone the team defends internally.
For your team
Tell me what your engineers are building and where it is falling over. I will tell you whether this half-day is the right thing and what it costs.