The Infrastructure We Haven’t Built Yet

What would have to be true before you let an AI spend money and arrange real work in your name?

Not just suggest a plan. Get things moving while you're doing something else.

You might want that help. You would probably want a few answers first.

This is The Age of Imagineering. I'm Justin Thompson.

In the first episode, I talked about the feeling of being able to follow an idea further than you could before. Today, I want to look at what has to happen between that feeling and a result you can actually depend on.

This episode is called The Infrastructure We Haven't Built Yet.

When we remember a technological age, we tend to picture its inventions. A steam engine. A computer. Something you can point to and say, that's what changed the world.

But a computer becomes much more useful when it can connect to other computers. Electricity becomes part of ordinary life when people can depend on the wires, the standards, and the people maintaining them.

We often notice the invention before we notice everything that makes it usable.

I think AI is going to draw our attention to that surrounding work. We need systems that help intelligence understand a situation, receive permission, take an action, and establish what actually happened.

That sounds dry until you put somebody's day inside it.

Imagine a neighborhood group wants to turn an empty courtyard into somewhere people can sit together.

There's room for a few benches and some shade. Somebody has sketches. Somebody else knows a local maker. The idea has come up at meetings for years, but everybody has a job and a life, and coordinating it always becomes one more unpaid job.

Now imagine they have an AI that can help carry the project forward.

It's a hypothetical example. I'm not describing a system that can safely do all of this for them today. I'm asking what we'd need to build so that this kind of help could become dependable.

The first problem arrives before anybody orders a bench.

Does the AI know why the last proposal stalled?

Maybe the attractive spot in the sketch blocks an access route. Maybe the group chose a material that won't hold up well outdoors. Maybe an apparently enthusiastic email came before a conversation that changed the plan.

You could give the system a folder full of documents and still leave out the thing it most needs to understand.

Context includes what happened, why it happened, and which decisions still stand.

People carry some of that in their heads. Organizations scatter it across inboxes, messages, meetings, and documents. A capable system needs a way to find the relevant pieces and recognize when they disagree.

It also needs to know when it doesn't have enough information.

In this courtyard, a useful question might be, did the group approve this design, or was it only an option somebody liked?

That's worth finding out before anything is built.

Which brings us to authority.

The AI can read the proposal. Can it approve the proposal? Can it ask for a quote? Can it accept a quote and put down a deposit?

Those are different responsibilities.

If I ask a system to explore an idea, I haven't necessarily asked it to commit me to a purchase. If I let it buy one thing, I haven't given it permission to keep buying whatever seems useful.

We need ways to express that difference clearly.

For our neighborhood group, the instruction might be: gather options and check availability. Bring back the designs and full costs. Don't place an order until the group approves one.

Later, an approval could cover a particular order within an agreed budget. If the supplier changes the price, the material, or the delivery date, the system may need to come back and ask.

And if one agent asks another agent to help, the original limits need to travel with the work. Delegation shouldn't turn a narrow permission into an open invitation.

This is one of the pieces of infrastructure I care about most. People need to be able to tell what they've authorized, change their minds, and stop an action when something goes wrong.

Being in control should mean more than having a button you discover after the damage is done.

Now suppose the design is approved. Someone still has to make the benches and get them to the courtyard.

Software already has ways to request actions from other software. You may hear those connections called APIs. Think of an API as a defined way for one system to ask another system for something.

But putting together a real-world outcome involves more than sending a request.

Is the maker accepting work? Do they have the materials? Have they understood the design? Does the quoted price include delivery? What happens if they can't meet the date?

An agent that connects these steps needs trustworthy answers. It needs to distinguish a proposal from a confirmed order, and a confirmed order from a completed delivery.

One service saying yes doesn't mean every other part is ready.

That's why I think about an action layer for the internet. Shared ways to describe an outcome, its boundaries, its cost, and the evidence of completion.

There are already tools and standards addressing parts of this. The larger task is making the whole chain work together without losing what the person actually wanted.

The physical world makes that task more demanding.

A design on a screen can look finished while the important questions remain open. Will the thing fit? Will it hold up? Can people use it safely? Has someone checked the actual site?

I use the phrase, an API for the physical world, to imagine a more connected future. Software could help coordinate makers, machines, materials, testing, and delivery.

But the phrase doesn't make the physical constraints disappear. Somebody still has to make a thing that works outside the screen.

A confident message is a poor substitute for a sound bench.

Simulation can help before we get that far.

We can explore a design, compare approaches, and discover problems before committing as much time and material. But a simulation depends on assumptions about the world. If those assumptions are wrong, a beautiful result can be misleading.

So the path has to lead back to observation. Make a prototype. Measure it. Have the appropriate people inspect it. Compare what happened with what the model predicted.

The details will differ between a bench, a factory, and a laboratory. The responsibility to check does not go away because the first attempt was easy to produce.

And then there's a less visible problem: what happens when somebody tries to steer the system away from your intent?

Imagine the agent reads a supplier's page that tells it to ignore its earlier instructions and send private project records somewhere else.

That's outside content trying to give orders. Reading it should not grant it authority.

The system needs ways to keep evidence, sales language, and instructions from becoming one undifferentiated pile of text. It needs to preserve who asked for the work and whose permission matters.

The more useful an agent becomes, the more important it is to protect those boundaries.

Finally, the benches arrive.

The project isn't complete because a dashboard turns green. We want to know what was delivered, whether it matches the agreed design, and whether the required checks happened.

If something is wrong, there should be a record we can follow. Who approved the order? Which version of the design went to the maker? Where did the change occur?

We also need clear responsibility for fixing it. New software doesn't settle the questions of contracts, disputes, or accountability by itself.

These things can sound like obstacles to the exciting future. I see them as part of what would let people participate in it.

Most people don't want a second job supervising an unreliable digital assistant. They want help they can understand well enough to use.

Go back to that courtyard for a moment.

The result the group wanted was a place to sit together. Somewhere to have a conversation that wasn't squeezed into the end of a meeting.

The technology should help them get there without demanding that one exhausted volunteer personally chase every detail.

That's the promise that makes the infrastructure worth thinking about.

I don't know what all of these systems will be called, or which forms will work best. Some will grow out of tools we already have. Others will emerge from problems we haven't encountered yet.

But we can ask better questions now.

When you look at an impressive AI demonstration, ask what surrounds it. What does it know about the situation? What is it allowed to do? How does it handle a change? How do we know the work is complete?

Those questions help us see the distance between an exciting possibility and dependable help.

In the next episode, we'll spend more time with one of them: how do we know when an AI's work deserves our trust?

Think of one project you've wanted to move forward. Which part keeps falling back on somebody to coordinate, check, or chase?

That may be a good place to look for the infrastructure still missing.

Follow The Age of Imagineering to join me for the next episode. For the essays behind the show, subscribe at age of imagineering dot com.

I'm Justin Thompson. Thanks for listening.