When one AI assistant is no longer enough

What we can take from Katy Šrámková’s agentic teams beyond software development: an orchestrator, micro-agents, independent checks and a course-design example.

At Meetup #2, Katy Šrámková showed a system she has built up step by step while developing apps: an orchestrator, narrowly focused micro-agents and a separate layer of checks.

The system solves a very ordinary problem: how to split more complex work so that errors don’t travel onwards unchecked.

← Full Meetup #2 recap

Why split the work at all

Katy started with a simple example. You take a recording of a talk and let AI transcribe it. There will already be errors in it. You turn the transcript into a summary, and the summary into another output. Every step works with what the previous one handed over – errors included.

On the slide she showed it with a model: every step corrupts a random 15% of the content.

The tricky part is that such output often looks great. It’s nicely formatted, detailed, it cites sources. That’s exactly why, according to Katy, it isn’t enough to trust it because it looks good – it has to be verified.

One more experience led her to split the work: a single agent working on a task for a long time gradually loses context and starts making things up.

One holds the whole. The others get smaller jobs.

In Katy’s system there is one orchestrator. That’s who Katy talks to – not the other agents directly. The orchestrator launches subagents itself, hands them work and collects the results. The agents communicate through the orchestrator, not on the side or directly with each other.

One decision turned out to be crucial: what the orchestrator passes on to the subagents. When Katy let it pass on its own memory too, they started interpreting the brief far too freely. Now they only get instructions – as a prompt and a set of rules.

“Micro-agent” is Katy’s own term. Her micro-agents have a really small scope: as if, when making a blouse, one could only recognise the material, another the colour and a third could only cut. That leaves them no room to drift, and the one deciding the colour won’t start doing something else.

In the talk Katy also mentioned the practical set-up: an agent needs to be able to save files, run and install tools, and work in loops – without waiting for a person at every step. Her orchestrator runs on medium reasoning and chooses the level each subagent needs. In her experience, maximum reasoning for everything made no sense.

The agent that built something doesn’t have to be the one that approves it.

The core of Katy’s system is on the slide “Software development with an agentic team”: one orchestrator, specialised implementation, independent verification.

For a more complex app, Katy keeps the tasks in GitHub Issues: she tells the orchestrator to pick up a specific request and the whole team works on it. For simpler projects she uses a text file with a list of requests that the orchestrator works through one by one. Functional micro-agents make the change and, once they agree it’s done, the orchestrator runs the verifiers.

She was also honest about what usually doesn’t fit into the diagrams: most of her time goes into testing the result herself.

Some checks need to run across the whole result.

Katy splits verification agents into three groups. Each answers a different question:

Functional verification also includes negative tests: checking not only that the result does what it should, but also that it doesn’t do what it shouldn’t. Katy illustrated this with an example from practice. The brief said a certain group of managers should have access to sensitive reports. Testers checked that they did. Nobody checked that no one else did – and because of a bug, almost everyone ended up with access.

Cross-verification is another of Katy’s own categories. Functional micro-agents each own one area of the app, such as sign-in, onboarding, tasks or reminders. Cross-verification micro-agents run across all of these areas, but each only watches its one thing:

• controls and accessibility: is it easy to use?
• language and formats: are texts and data understandable?
• security and errors: do we protect data even when something fails?
• data consistency: do the app and the server understand each other?

She showed why this matters with buttons. The agents create a button, then another and another, and each is slightly different. When you later want to change the colour of all buttons, only one changes, because they don’t use a shared component. Only a check that looks across the system finds that kind of error.

The general principle

Katy’s presentation itself ends by moving from software development to “The general principle – or how to apply it to other kinds of tasks”. It has three steps:

And one note from the slide that’s easy to miss: the analysis itself can be done using the same principle.

What the same principle could look like in course design

This is where it got interesting for my own work. So I tried to translate the principle into a process I deal with: creating an online course.

The following example is no longer Katy’s system. It’s my application of the same principle to a different type of work.

I didn’t start with a team of agents. First I had one skill for components in our LMS, then another for activities, then one for research. The orchestrator came when I could no longer remember which skill did what. Today I have two modes: for a new course, the orchestrator first interviews me and then runs the whole team. When I only want to add one activity, it calls just that one agent.

Just like in Katy’s system, what matters most is the split of roles: who creates, who checks independently and where a person decides.

You don’t have to start with a team of ten agents.

For one recurring workflow, I would start with three questions: