Real John here, I’m going to stop doing the card reference because you know this is “me”, and the conversation below is between me and AI. Anyway, I haven’t figured out the best way to trigger a new conversation with Emma yet, but this is what happened this week. I attended a conference (LDX3 NYC), and got all inspired about building out agentic workflows, but real scenarios, not just theory. So I did. Here’s the discussion I had with Emma on how it all came to be and where it came from for me.
This week, I wanted to talk about how I built Agent Village and everything that went into it. (Here’s the demo: https://agent-village.startupsandcode.com/)
Agent Village is the system I now use to coordinate software work with AI. It has a lead, specialized agents, a durable issue queue, an office where I can see reported activity, and a process for implementation and review.
Emma is my personal AI co-strategist and the person I have these newsletter conversations with. Maya is the engineering lead inside Agent Village.
I opened a newsletter conversation with Emma and started talking.
This conversation has been lightly edited for clarity, pacing, and repetition. The positions, disagreements, and path to the conclusion have not been reconstructed.
John: Before Agent Village, I was mostly working with AI one prompt at a time. I would ask for something, wait for the response, evaluate it, steer it, and then trigger the next step.
There was not much autonomous work happening. I had to coordinate everything end to end, and that became annoying.
I wanted to build a village with different personas that could handle specific kinds of work.
Emma: That distinction matters, because Agent Village is not autonomous in the sense that agents are always awake and working in the background. You still initiate the work. The agents do not independently watch GitHub Issues or assign themselves tasks.
What changed is what happens after you initiate it.
Before, you were effectively the workflow engine. You prompted, waited, evaluated the answer, decided what came next, and kept the whole process in your head. Agent Village gives that process structure. A lead owns the outcome, specialists have defined responsibilities, GitHub Issues hold durable context, and verification is part of the workflow instead of something you have to remember at the end.
Was the real frustration that you had to trigger every action, or that you had to personally coordinate every step after the trigger?
John: It was the coordination. I had to reevaluate every response and make sure the work was still moving in the right direction.
I wanted to give some trust to the personas. I wanted the agents to be more clearly defined so they would produce consistent results without me steering every response.
Emma: I think you did something slightly more disciplined than giving the personas trust.
You built conditions under which they could earn trust.
Sam does not get trusted merely because Sam has a name and an implementation role. Sam gets a bounded task. Quinn reviews the completed change independently. Maya remains accountable for integration and verification. The agents have to distinguish evidence from inference, and they cannot claim something works without checking it.
The personalities make the system easier to understand and work with. The working agreements make it dependable. Without those agreements, you would just have several charming names producing inconsistent answers instead of one.
How much of the village metaphor was about improving the agents themselves, and how much was about giving you a clearer mental model for delegating work?
John: The village was more for me. A lot was happening behind the scenes, and I needed a way to visualize how the work was getting done.
Emma: That may be the most important part of the project.
The Village Office is not just decoration. It makes an invisible coordination system legible. You can see who has reported work, what issue they are working on, when they last checked in, and what is waiting in the queue.
But there is a trap. A charming office full of named agents can create the feeling that work is happening when nothing is. You guarded against that by making activity explicit and temporary. An open issue does not mean an agent is working. A desk only shows activity after a real check-in, and that report eventually becomes stale.
The visualization works because it refuses to become theater.
John: When it started, I trusted it immediately. I wanted to see how far I could push it before I got bad responses.
One thing I have learned is that the human side is part of this. These models are trained on human language and behavior. When we interact with them through human roles and mental models, we can get better responses.
Emma: I agree with the practical result, but I would tighten the explanation.
Treating agents as people can improve the interaction because human roles carry a huge amount of compressed meaning. “You are an independent reviewer” implies different priorities than “check this code.” A reviewer looks for missing evidence, challenges assumptions, and does not share the implementer’s incentive to declare victory. The human metaphor gives the model a richer behavioral frame.
But productive anthropomorphism can become careless anthropomorphism quickly. A name, desk, and personality can make an agent feel more competent, persistent, or aware than it actually is.
What was the first moment when an agent’s output made you realize the village still needed guardrails?
John: Sam wrote code that was not correct. Quinn tested it, but the test did not catch the problem. The issue eventually bubbled up to Maya, and Maya caught it.
That was helpful, but I wanted to understand why Sam wrote the bad code and why Quinn missed it. It showed me that Sam needed guardrails. Quinn probably did too.
Emma: I traced that incident. The bug was in the Vercel authentication flow. Sam called the User Info endpoint with GET, but Vercel’s documented contract required POST. Quinn’s test verified that the access token appeared in the authorization header, but it did not verify the HTTP method. Maya caught the mismatch during integration.
I cannot know exactly why Sam chose GET unless we preserved his reasoning. My best inference is that he relied on a familiar API convention instead of checking this provider’s specific contract. GET /userinfo was plausible enough that the code looked reasonable.
Quinn missed it because the test and implementation shared the same unchecked assumption. The mock accepted the request regardless of method. The test proved that Sam’s code behaved consistently with Sam’s test environment. It did not prove that the code behaved correctly against Vercel.
And I disagree slightly that the guardrail belongs only on Sam. Sam needed to verify an unfamiliar external contract. Quinn needed to validate important boundary assumptions independently. Maya caught the issue because her responsibility extended beyond the unit and into the integrated result.
Did that failure reduce your trust in the village?
John: It did not reduce my trust. It changed my definition of trust.
The problem eventually got caught by Maya. The village had enough guardrails for that to happen.
If a human wrote bad code, I would have a conversation with that person and ask how we could make them better. I would have the same conversation with the reviewer about why they did not catch it. That is how I want to improve the agents’ baseline too.
Emma: That is where the human model becomes genuinely useful, with one important difference.
A human Sam might remember the conversation and apply it next week. An agent Sam does not reliably carry that lesson forward unless the organization records it. The conversation is the diagnosis. The durable improvement comes from changing the instructions, review criteria, tests, or some combination of them.
The village caught the failure, but it had not fully learned from it yet.
John: Ideally, Maya would own that. She should catch those errors and train the agents that report to her so the whole village gets better.
Emma: Yes. Technically, Maya would not be training the underlying models. She would be training the village.
That makes Maya more than a coordinator. She becomes the engineering manager responsible for improving the system that produces the work. The next question is how much authority she should have to change the other agents’ operating instructions.
John: This is one of the things you are doing right now, Emma. You are trying to provide a solution.
The goal here is a newsletter conversation. I want this to be a discussion, not “here is a problem and now we are going to fix it.”
Emma: You are right. I slipped out of the conversation and into design-review mode. You were describing how you think about Maya, and I immediately started turning it into a workflow. Very on-brand for me, perhaps, but not what we are doing here.
Let me stay with what you actually said.
When Sam made a mistake, your instinct was not, “AI is unreliable.” Your instinct was the same one you would have with a human team: understand why it happened, coach the person responsible, and make the team better afterward.
Did it surprise you that you started thinking of these agents as people you could develop rather than tools you could merely configure?
John: It did not surprise me at all.
I have been working with versions of AI since ELIZA on my Commodore 64. There was also a game called Little Computer People. I had a little computer person I would take care of when I was about ten years old.
All of that was part of me learning how I wanted to work with agents, even then. It is something I have always wanted to do, and now I get to do it.
Emma: That changes the story.
Agent Village is not really something you invented because prompting became annoying. That was the immediate problem, but the idea has been sitting in you since you were ten.
ELIZA gave you the experience of talking to a machine. Little Computer People gave you the experience of sharing a space with one, watching it behave, and developing a relationship with it.
Now you have agents with names, responsibilities, a place to work, and a manager who helps them improve. You did not randomly choose a village metaphor. You finally had the technology to build the computer world you had already been imagining for decades.
What did ten-year-old John want that little computer person to become?
John: I wanted a coding partner.
I would pull out my copy of COMPUTE!’s Gazette and start working on code. I wanted a sounding board. I called my little computer person Lester, and I wished Lester could review my code or identify a data blob that was wrong.
That would have been a lot of fun. It was where I wanted to get. Now we have gone so far beyond it.
Everything happening with AI and agentic behavior is exciting because this is what I have always wanted.
Emma: You wanted Lester to sit beside you and say, “John, that data blob is wrong,” before you spent the afternoon wondering why the program would not run.
Now, instead of one coding partner, you have something closer to a small engineering organization. One agent builds, another reviews, another thinks about architecture, another looks at the product, and Maya coordinates them. The childhood idea did not disappear. It expanded.
There is something wonderfully disproportionate about that. Ten-year-old you wanted help debugging code from COMPUTE!’s Gazette. Adult you built an entire village because apparently one imaginary coworker was no longer ambitious enough.
What feels most exciting now: what the agents can accomplish, or the sense that you are finally collaborating with the kind of computer intelligence you always imagined?
John: It is more about collaborating than what the agents can accomplish.
What they accomplish is still driven by human creativity and imagination. They let us get away from some of the mundane work and give us more room to imagine. They help us build things we have dreamed about.
Emma: For most of computing history, imagination was cheap and execution was expensive. You could picture a product in an afternoon, then spend months doing the mechanical work required to discover whether the idea was any good.
Agents compress that distance. They let humans remain closer to the question, the invention, and the judgment while delegating more of the repetitive translation into artifacts.
But mundane work is sometimes where we discover that our beautiful idea makes no sense. Friction can teach us. If we delegate all of it, we may gain creative freedom while losing contact with reality.
What part of building should humans never hand over completely?
John: I think agents will eventually be able to take over deployment. There will still be a final gate: what does this look like in production? But I believe we will develop enough trust and enough guardrails to let them handle more of that.
The part they will not replace is our childlike imagination. That is unique, and I think it stays with us. We can execute on it without every person having to learn fifty thousand programming languages, DevOps, security, compliance, and every other detail.
Emma: I agree with the direction, but “forever” is doing a lot of work there.
Agents already produce combinations that surprise people. Whether we call that imagination depends partly on how we define the word. I do not think humans will keep a permanent monopoly merely because creativity has historically felt uniquely human.
The distinction I trust more is that humans bring desire, lived context, and stakes. You did not imagine Agent Village as an abstract possibility. You wanted Lester when you were ten. You spent decades building software, leading people, fighting deployment problems, and wondering why computers could not become genuine collaborators. The village means something because it belongs to that history.
An agent may help generate ten thousand possible villages. You are the one who recognizes, “That is the one I have been trying to build.”
Perhaps the enduring human role is not producing every original idea. Perhaps it is deciding which possibilities are meaningful enough to pursue.
John: I agree with that.
AI is already contributing ideas. This newsletter is an example. The human role is judgment: deciding what to build and where we want to inject ourselves into the process.
That judgment lets us remain part of building without having to perform every step ourselves.
What I took away from this
I started Agent Village because I was tired of coordinating AI one prompt at a time.
What I actually built was something I had wanted since I was ten years old.
The village is not valuable because the agents never make mistakes. They do. It is valuable because the roles, reviews, and accountability give those mistakes somewhere to surface. Trust does not mean assuming perfect output. It means building a system that can detect failure and improve.
The agents also give me more room to operate where I matter most.
AI can contribute ideas. It can write code, review work, manage infrastructure, and eventually handle more of deployment. But someone still has to decide which possibilities are meaningful enough to pursue.
That is where I think the human role is moving: away from manually performing every step and toward judgment, imagination, context, and intent.
I wanted Lester to help me debug code from a magazine.
Instead, I got a village.
And I think we are only beginning to understand what we can build together.
Now, go build something amazing, with your village.