The Agentic Nephew.

When I was seventeen I had a paper route, and I did something with it that I'm only half proud of.

I worked out that the route wasn't one job. It was two. There were the easy addresses, close together in the neighbourhood, which you could do on a bike without thinking. And there were the far and distant ones, scattered across the edge of town, where you really wanted an engine. So I asked a few other kids to do the easy addresses by bike. I took the far ones myself, on my scooter. And I kept three times as much per address as they got.

Not an entirely nice story. I'm aware.

But the principle holds, and it's the one I keep coming back to this year. One person who understood the whole route split it up, matched each part of the work to the right vehicle, and handed the simple chores to people who didn't need to understand the whole route to do them well. I didn't have the vocabulary for it at the time. Today I'd call myself the orchestrator, and the neighbourhood kids sub-agents.

I bring it up because the AI most of us use has started doing exactly this, on its own, without asking. And most people haven't noticed yet.

What comes in the harness

The harness gives the nephew four things. Each has a technical name you'll run into in the documentation, and each has a plain meaning that is more useful to you.

A manual. These are called skills. Think of an encyclopedia he can look things up in, so he doesn't have to invent or relearn everything from scratch every time. When he goes to the corner shop to pick up food, there's a chapter on how to buy food and what a good price is. At the register there's a chapter on paying. Technically, a skill is a fixed set of instructions written for one kind of task, which gets sent to the model every time you ask for something in that area. (Writing your own is easier than it sounds. I start from a list of what only I do, in The Only-Me List.)

A clock. These are called loops, schedules or cron jobs, which is the Linux name. Your nephew, like many teenagers, gets distracted. When he's done, or thinks he's done, he wanders off and does something else. Or, as far as you're concerned, nothing. The clock is a timer plus a memo. Every time the alarm goes off he has to read the memo again, and the memo says: you're still working for your aunt or uncle, and you're on a mission to do X. Technically, it's a prompt that runs every few minutes and gets the agent moving again. This is the real difference from just asking a model to build something. A single request ends when the model decides it's finished. A clock brings it back.

A workspace. These are folders, sometimes repos (repositories, folders with version history built in), where the agent works and keeps track of what changed. Don't think of a new workspace as sending your nephew somewhere else. Think of it as an entirely new nephew. He doesn't remember what the other one knew. That turns out to matter a lot, as you'll see.

Keys. These are called connectors, and they come in many shapes: MCP connectors, plugins, APIs running on your network, webhooks. In plain terms they are drawers you give him the key to. Phone numbers. Helplines. Maybe even your bank card. Whatever you allow him to use while he's helping you. And he shares all of it with his brothers and sisters.

That last point is the paper route again. Harnesses split the work by default: an orchestrator role that holds the whole route, and sub-agent roles that take the easy addresses. You don't have to set this up. You do have to know it's happening.

Trick one: say it lazily, then make him write the plan

Most harnesses do some version of this by themselves, but everyone should know the idea: brief, then a build plan, then an implementation plan, before anything gets built.

The lazy prompt. You can get away with a high-level ask now. What matters is what you ask him to do next.

“I'd like you to build me an executive dashboard. Interview me with questions until you have all the information you need to come back with a good first proposal for a build plan.”

You should get a series of questions back. Some models will quickly sketch visuals too. Take your time here. This is where you check that he understands what you want and need, and that he knows which data sources he can actually reach. If he doesn't know where the data lives, he'll guess, and you'd much rather find that out now than in the finished dashboard.

The build plan. When the questions run out:

“Turn this into a build plan. Map out the architecture, the tools and web technology it needs, where the data comes from, and how the finished thing gets distributed and shown to me. Write it for someone who isn't an engineer.”

This is a document you should actually read, and read well. If parts of it make you uncomfortable, only correct and comment on the parts you understand. Don't pretend about the rest. For the rest, there's a trick: copy the whole build plan into a chat window, the Gemini app or whichever one you like, and talk it through with a model until you get it. It's the cheapest tutor you'll ever have, and it never sighs.

The implementation plan. Then:

“Turn the build plan into an implementation plan: clear, numbered instructions that any of your brothers and sisters could pick up and deliver without having been part of this conversation.”

That last clause does a lot of work. The sub-agents weren't in the room. They only know what's written down. (If that sounds like onboarding a new team member, it is. That's the whole argument of Agent Inclusive.)

In one line: tell him what you want, let him explain back how he'll build it, then have him write the plan all the nieces and nephews will build from.

Sequencing, if you want it to run on its own. Don't just say “now implement the plan.” Say this:

“Turn the implementation plan into a to-do list in the right order. For each item, mark whether it can be done in parallel with others or depends on something else first, and take that into account when you set the order.”

That one question, what can run side by side and what has to wait, is the difference between a list and a schedule. It's also the question any project manager asks, which is a nice reminder that none of this is as foreign as it sounds.

Trick two: the build loop

Now, instead of telling him “build it,” you put him on the clock.

“Start a loop that runs every 15 minutes. Each time, pick the next open item on the implementation list and work through it. When you think it's done, start a separate agent to test whether it was actually built as described. If the test passes, strike the item through and mark it completed in the implementation plan.”

Next time the alarm goes off, he opens the next item that hasn't been built yet. Step by step by step. It's the simplest way I know to explain how agents work. Given a list of a thousand things, he'll do all thousand by himself, until he hits one he can't finish or can't get past the test. Then he stops, and that's where you come in.

Two details carry the weight. The separate test agent matters because the builder is a terrible judge of his own homework, like most of us. A fresh nephew who only has the plan and the result, and no pride in the work, is a much better inspector. And the strike-through matters because the list is the memory. When the alarm wakes him, he doesn't remember the last fifteen minutes. He reads the list.

You can make this much richer. You can run the entire process above in a loop: write down each step you'd normally take on a project, make that the memo, and set the clock to sixty minutes. You can run several loops side by side. But start with the simple one. It teaches you how the nephew behaves when you're not watching.

Trick three: the gauntlet

This style of loop has become very popular right now, and it's the one I'd use for work where quality is the point and not just completion: a strategy review, a market deep dive, a board pack. It runs in a cycle:

1. Show him what good looks like. Give him a very clear reference for how the result should look, feel or read. “Here's an excellent consulting presentation. Study its structure, its completeness, the quality of its data.”
2. Build. “Do a deep dive on my home energy data. Be very structured. Analyse A, B and C.”
3. Independent review. He hands his work to a different agent, who compares it with the reference and gives back one pointer: the single most important thing to change.
4. Grade. The cycle starts again. After making the change, he has to grade whether the report got better or worse. If it got worse, he tries fixing the same thing again. If it got better, he moves on to the next pointer.
5. Stop. He keeps going until the reviewer can't find an improvement for three, four or five rounds in a row.

That last rule is the one people skip, and it's the one that saves you. Without a stop rule, an eager nephew will polish forever, and past a certain point polishing is just a nicer word for drift. A plateau rule (if three rounds in a row bring nothing better, you're done) is how you tell a loop that “good enough” exists.

As one prompt:

“Run a gauntlet loop. Here is the reference for what good looks like: [reference]. Build a first version of [the work]. Each round, a separate reviewer agent compares the latest version with the reference and gives exactly one improvement. Apply it, then grade whether the result got better or worse. If worse, retry the same fix. If better, take the next improvement. Stop when three rounds in a row produce no improvement, and tell me what changed in each round.”

Notice what the human job is here: writing the reference. Saying exactly what good looks like. The loop does the polishing, but the reference is what decides where the polishing ends up.

The catch: the house gets messy

Everything so far comes from how people code with AI, applied to business. Now the caveat, and it's the part I'd most want a newcomer to hear.

As your agents spin up, learn more and do more, the workspace they operate in gets contaminated. The nephew feeds on the documents you create, so he also picks up information from every other document lying around in the same workspace.

Models are almost fanatical about finding extra context to help you better. That's the eagerness, and most of the time it's a feature. What they don't know is which information is fit to share. I don't mean that in the data-protection sense, though that matters too. I mean this: you're halfway through a piece of research. There are intermediate conclusions in the folder that haven't been checked and aren't final. Another nephew stumbles on them, finds them useful, and starts using them in a study that needs business-critical, verified information. Nobody lied. Nobody broke a rule. A draft just walked out of the kitchen dressed as a fact.

Isolated, then layered, then governed

Step one: isolate. Think in silos. Only give each agent access to a very specific workspace, and be deliberate about building isolated ones.

The catch is that in isolation everything has to be reinvented every time. Each new nephew works it all out from scratch. Skills are one answer: whenever someone figures something out, bake it into a skill and use the skill next time. That's the manual doing its job. But there's a more scalable, structured way.

Step two: layer. Organise your workspaces the way a sensible company organises departments, by what they do to the information:

1. Gathering: pulling the data in.
2. Processing: cleaning and shaping it.
3. Study: the analysis and the conclusions.
4. Visualisation: the dashboard, the deck, the thing people look at.

Each layer reads only from the one below it. A half-finished study can't leak into the gathering layer, and nothing reaches the dashboard without passing through study first.

Step three: govern. On top of the four layers, add one overarching workspace whose job is learning between them. It:

• runs spot checks on data integrity;
• watches for cross-contamination between layers;
• looks for patterns. “Here's something three different agents figured out on their own. Let's turn it into a skill.”

That last job closes the loop on isolation. The silos keep work clean, and the governance layer makes sure what one silo learns doesn't stay trapped there.

“Set this project up as layered workspaces: gathering, processing, study and visualisation. Each layer may only read from the layer below it. Add a governance workspace above them that runs a daily spot check on data integrity, flags anything that looks like unverified work moving between layers, and proposes a new skill whenever it sees several agents solving the same problem on their own.”

What you give him the keys to

One honest caveat, so this doesn't read like a brochure. Everything above gets more powerful with every connector you add, and so does every mistake. The nephew is eager, not malicious. But an eager agent with a company card is still an eager agent with a company card. And remember: whatever keys you give him, he shares with his brothers and sisters.

So be stingy, especially at first. Give read access before write access. Give one folder before the whole drive. Anything that sends, pays, publishes or deletes should wait for a human to say yes, at least until you've watched him handle it many times. And the keys are usually not yours to hand out: your company's data, systems and accounts come with owners and rules, so talk to whoever looks after them before you plug the nephew in. I'm not a security engineer, and this isn't a security guide. It's the minimum I'd want someone to know before their first loop runs overnight.