James Moss

Most teams using coding agents hit the same wall. The agent writes code quickly, but someone still has to review it, check it for security problems and keep an eye on what it costs. A software factory hands those jobs to agents too, and what makes it work is context: the instructions, rules and skills that tell each agent how your team does things.

In this hands-on workshop you'll build one. You'll use the Tessl agent to work through it step by step. Along the way you'll set up automated code review, add security checks, plug in reusable skills and get a handle on token spend. Where a piece isn't built in yet, we'll show you how to approximate it with a simple agent loop.

You'll leave with a working repo you can keep building on, and an approach that carries over to whichever agent your team uses.

Who it's for

• Engineers and tech leads already using a coding agent such as Claude Code, Cursor, Codex or Gemini. You should be comfortable with git and the terminal. No Tessl experience needed.

What to bring

• A laptop with git, Node.js and your coding agent installed
• A GitHub account
• A repo you'd like to try this on (optional; we provide a starter)

We'll give every attendee extra credits on the day, so nobody runs out mid-session.

Adding more coding agents does not multiply output cleanly. It creates a coordination system with new failure modes: agents editing the same code, maintenance work triggering more maintenance work, tasks competing for shared state, and failures that no single agent appears to own.

This session is a field report from scaling an internal software factory from individual agent runs to concurrent, connected workflows. We will examine what breaks when agents stop operating in isolation, including conflicting changes, recursive triggers, non-deterministic execution, and recovery paths that create more work than the original failure. The focus is not generic multi-agent theory. It is the practical risk of letting multiple coding agents act on the same repositories, queues, and delivery process.

Attendees will learn where orchestration needs explicit ownership, isolation, idempotency, and stop conditions, plus how to design systems that detect collisions and recover without silently compounding the problem.

We started where most developers start: one person, one agent, tinkering at the desk and getting things done faster than before. Skills are everywhere right now and the clever ones do genuinely impressive things. For solo work, that's usually enough.

It's a different story when you try to work as a team with the same approach, and it's not something people talk about much yet. Your codebase now has a new layer: skills, context files, agent instructions. The stuff that tells your AI coding agent how to behave. It lives alongside your code but gets none of the same treatment. No versioning, no review, no shared source of truth. Everyone's agent is doing something slightly different and nobody knows why.

We'll share what we learned the hard way: what broke, what we borrowed from how we already manage code, and what it actually takes to make your agent context something your whole team can build on top of.