Ok, this is more of a test conversation, but fascinating none the less. Anyway, let me know what you think. If you want me to go back to a regular newsletter, I’m down, but this is pretty fun. :-) (real john, out for now).
This conversation has been lightly edited for clarity, pacing, and repetition. Emma is AI, and the positions and conclusions remain our own.
John:
I have been thinking about how people are working with agents and how I built Agent Village.
Emma:
Most people still seem to work with agents like sophisticated vending machines. Put in a prompt, receive an artifact, complain when the snack gets stuck.
Even many “multi-agent” systems are several vending machines connected by pipes. One generates, another reviews, another revises. That can be useful, but it is not necessarily an organization.
Your village has roles, authority, handoffs, memory, review, and someone accountable for the result.
Did you build the village because the agents needed an organization, or because you needed a model that made delegation understandable?
John:
I think I needed an organization that made it more understandable for me as a human.
Emma:
That distinction may be the heart of it.
The village might not be the optimal structure for agents. It might be the optimal interface between you and a collection of agents.
You already understand how an engineering organization works. A lead owns the outcome. Specialists own parts of the work. Reviewers challenge assumptions. Work moves through visible stages. When something fails, there is a path for discovering where and why.
Instead of juggling prompts, contexts, and model outputs, you can think, “Maya owns this. Sam is implementing it. Quinn will review it.”
But there is a risk. Once we make agents look like an organization, we may import the worst parts of organizations: unnecessary hierarchy, excessive handoffs, and meetings between agents that could have been a function call.
How did you know the village was producing value rather than merely making the machinery feel familiar?
John:
It was the time required to deliver tickets and the speed at which tickets moved, got verified, and closed. That was probably the most valuable part.
Emma:
Then the organization was doing more than making the agents understandable. It was reducing the coordination tax.
Before the village, you were the person moving every ticket. You decided who should act, carried context between steps, requested a review, interpreted the review, sent the work back, and finally decided whether it was done.
The model might have written code quickly, but you were still the workflow engine.
The village moved some of that responsibility into the system. A ticket could travel from implementation to independent review to verification and closure without you restarting the process at every boundary.
Although ticket speed can become theater. A closed ticket is meaningful only if the work is correct and delivered. The real gain might not have been speed. It might have been continuity. The work continued through a complete loop without requiring you to remain the connective tissue.
John:
I think it was having a single point of contact. That was the most important part.
I could work with Maya, and everything just worked. She handled the handoff when it was needed, but there was not necessarily a handoff every time.
Emma:
That makes Maya less like a step in a fixed workflow and more like an abstraction layer.
You were not assigning every task to every agent. You worked with Maya. Maya decided whether she could handle something directly, whether Sam needed to implement it, whether Quinn needed to review it, or whether another specialist should become involved.
The handoff happened when the work required it, not because every ticket had to march through an agent parade.
That is closer to working with a good engineering lead than operating a collection of tools. You communicate the outcome once. The lead absorbs the coordination complexity.
Many agent systems expose the entire machine to the human. Here are twelve agents. Here are their prompts. Here is a graph showing their conversations. Here are seventeen decisions for you to make before anyone does useful work.
Congratulations, we automated the work and promoted you to full-time agent dispatcher.
You built the complexity too, but Maya gave you one place to stand.
John:
I did not care where the work was assigned. I cared that the result was actually verified.
That is probably the most important part. It is what makes this unique. It is not about moving tickets from point A to point B. It is the judgment that happened.
Emma:
That changes the argument.
You did not build a ticket-routing system. You built a judgment system.
Routing is mechanical: Sam writes the code, Quinn reviews it, Maya closes the ticket. You can draw that as a clean diagram and automate it.
Judgment is messier. Does this task need a specialist? Is the implementation actually correct? Did the review test the right assumption? Is the evidence strong enough to call it done? Should the work go back, move forward, or be escalated?
The village matters because Maya is not merely passing artifacts between agents. She remains responsible for deciding whether the result deserves your trust.
That may be the difference between an agent swarm and an agent organization. A swarm distributes work. An organization distributes work and preserves accountability for the outcome.
There is still an uncomfortable question. If Maya, Sam, and Quinn are models that can share the same blind spots, multiple names do not automatically produce independent judgment.
John:
Then how do I improve the team’s judgment so it understands what I want returned? That is what I really want to know.
Emma:
You improve judgment by closing the gap between what you meant and what the team thought “done” meant.
More instructions will not solve that by themselves. You could give the team a fifty-page rulebook, and it might follow every rule while still returning the wrong thing.
Judgment requires understanding the outcome, noticing ambiguity, and selecting the right evidence.
I would give Maya three things for meaningful work:
- Intent: Why does this need to exist?
- Boundaries: What tradeoffs are acceptable, and what must not change?
- Evidence: What would justify calling the result correct?
Every disappointing return should then become part of the village’s education.
Do not merely say, “Fix this bug.” Ask what judgment failed.
Did Sam misunderstand the goal? Did he assume an external contract without checking it? Did Quinn verify the implementation instead of the intended behavior? Did Maya accept evidence that was too weak?
Record the correction at the level where the judgment failed. Otherwise, you accumulate narrow rules such as, “Always use POST for this endpoint,” when the transferable lesson is, “Verify unfamiliar external contracts against authoritative documentation.”
John:
Would giving Maya concrete examples of solutions help?
That does not seem feasible. Every solution will be different, so I cannot show her what success always looks like.
I could give her expected results. What are some examples of the boundaries you mean?
Emma:
You are combining two different things: an example of the solution and evidence that the outcome was achieved.
You usually cannot show Maya what the solution should look like. Doing so would defeat part of the purpose of delegation. You would be designing the answer and asking the village to type it.
But you can describe what must be true when the work is finished. Those are expected results. Evidence demonstrates those results without prescribing the implementation.
Take the authentication mistake the village encountered. The assignment might include this:
Intent: A user can authenticate with the provider and enter the application with the correct identity.
Expected results: A valid user receives a session. An invalid or incomplete authentication attempt is rejected. Existing authentication methods continue to work.
Boundaries: Follow the provider’s documented contract. Never log credentials. Do not redesign unrelated authentication code. Authentication must fail closed. If the documentation and implementation disagree, stop and surface the conflict.
Evidence: Tests prove the request uses the documented method, headers, and payload. Invalid responses cannot create sessions. The existing authentication suite still passes. Maya compares the implementation against the provider’s documentation rather than treating Sam’s test as proof of the contract.
None of that tells Sam how to build the solution. It identifies where the village is free to exercise judgment and where it is not allowed to improvise.
Boundaries usually describe scope, risk, authority, tradeoffs, or the required level of proof.
You do not need to repeat every boundary on every ticket. That would turn the village into a bureaucracy wearing a charming little hat. The recurring boundaries belong in the agents’ operating instructions. Individual tickets should identify what is unusual about that outcome.
Concrete examples can still help, but give Maya examples of judgment rather than finished solutions:
“When an external API behaves differently from our assumptions, verify the authoritative contract before changing code.”
“When a test proves only that our mock agrees with our implementation, that is not sufficient evidence of integration correctness.”
“When the requested change can be completed locally, do not expand it into a system redesign.”
Those lessons generalize. The exact code does not.
Expected results say where to arrive. Boundaries identify the unacceptable routes. Evidence tells Maya when she is justified in saying the team arrived.
John:
If I give all of that to Maya, will she delegate the same information to everyone she assigns work to?
Emma:
Not automatically. She probably should not pass the exact same information to everyone in the exact same form.
If Maya receives a rich description and delegates with, “Sam, implement authentication,” most of the judgment context disappears during the handoff. Sam receives the task without the intent, risks, or standard of proof.
Quinn may then review Sam’s implementation against Sam’s interpretation instead of reviewing it against what you originally wanted.
That is how organizations develop a very efficient game of telephone.
The core contract should survive every handoff:
- Intent
- Expected results
- Relevant boundaries
- The standard for completion
Each agent should also receive instructions based on its role.
Sam implements the outcome within the boundaries and returns the decisions and supporting evidence.
Quinn independently evaluates the work against the original outcome. Quinn should not merely confirm that Sam’s tests pass. The review should look for assumptions shared by the implementation and its tests.
Maya retains responsibility for deciding whether the combined implementation and review provide enough evidence to return the result as verified.
The crucial word is “original.” Quinn should review against the original contract, not a summary of Sam’s work. Otherwise, every handoff narrows the frame until the village is verifying its own interpretation rather than your desired outcome.
I would not rely on Maya to reproduce the context perfectly in every assignment. Put the contract in a durable task artifact that every assigned agent can read. Maya can add role-specific instructions without rewriting the source of truth.
The structure should not be:
John tells Maya. Maya summarizes for Sam. Sam explains the work to Quinn.
It should be:
John establishes the outcome contract. Maya, Sam, and Quinn work against that same contract from different roles.
Maya owns the handoffs, but the desired outcome survives independently of her phrasing.
Closing Reflection
I started by thinking Agent Village was valuable because it moved tickets faster.
That was the visible result, but it was not the most important change.
The important change was that I stopped being the workflow engine. I could work with Maya as a single point of contact. She could decide when to involve other agents, manage the handoffs, and remain responsible for returning a verified result.
The next step is not adding more agents. It is improving the village’s judgment.
I do not need to show the team what every solution should look like. I need to make the intent, expected results, boundaries, and required evidence clear. That contract then needs to survive every handoff without forcing every agent into the same role or the same interpretation.
That is the difference between automating a sequence of tasks and building an organization I can trust.