The Collapse of the Middle: How AI-Native Work Actually Happens

You have probably seen the stories by now.

One person ships what used to take a team. A small company moves like a much larger one. A founder seems to have a staff sitting behind a chat window. Product work that used to take weeks gets compressed into days.

If you have not lived inside this shift, it is hard to know what to believe.

I understand that. From the outside, a lot of AI still looks like prompts, tricks, demos, and hype.

But after taking two years off to focus on this, I think the real story is more practical. I used AI across the entire product development lifecycle and felt the work evolve as the systems became capable of doing more.

At first, I used AI for almost everything I was already doing in product development. For small tasks, a chat session was enough. Anything larger exposed the first problem: the work had to survive between sessions. That is when persistent context and files became important.

Then I saw AI operating inside workflows I already knew. Discovery, design, engineering, implementation, and review had always taken time. The gaps between them made the feedback cycle slow by nature. Once AI could work inside those stages, the time collapsed. Work that had been separated by days could happen almost immediately, so the feedback cycle sped up with it.

Eventually, the work became less about asking AI for an answer. It became more about designing a system that could move an outcome forward, check its own work, and retain the context for the next run.

The leap was not better prompting.

The leap was embedding intelligence into the work.

That path begins with prompt engineering. It moves through context, harness, and loop engineering. Eventually it leads to personal agents and company brains.

Once you see that path, the future of work becomes much easier to understand.

The real AI journey

Most people meet AI through chat. That makes prompt engineering feel like the whole subject.

It is only the first stage.

Prompt engineering
    -> Context engineering
    -> Harness engineering
    -> Loop engineering
    -> Personal agent / Company brain

Each stage keeps the intelligence from the previous one. What changes is how deeply that intelligence is connected to the work.

The easiest way for me to explain this is through the product lifecycle and the software development lifecycle. Those are real systems that many people in my network know well. They also make it obvious where AI is useful and where a clever demo is still only a clever demo.

Prompt engineering: AI as a place you visit

Prompt engineering is how most of us started.

You open a chat. You describe a problem. The model gives you information, a draft, an explanation, an idea, or a piece of code. You carry that answer back into the work.

A product manager might ask AI to draft a ticket. An engineer might ask it to explain an error. A designer might ask it to list edge cases. A founder might ask it to challenge a product idea.

The pattern looks like this:

Work problem
    -> Chat with AI
    -> Receive an answer
    -> Carry the answer back to work

This is useful. It is also limited.

The model only knows what you put into the conversation. It does not automatically know the product history or customer feedback. It cannot see the codebase, roadmap, architectural decisions, team constraints, or the last five times the same issue appeared.

The human still has to assemble the question and inspect the answer. Then someone must translate it into the real environment and move it into the next system.

Prompt engineering lets us interact with intelligence. It does not yet change the operating system of the work.

Context engineering: give AI the world around the task

The next stage begins when we stop treating the prompt as the whole input.

We give AI the files, data, examples, constraints, decisions, and history around the work.

For a product team, that context might include:

• the product strategy;
• customer interviews;
• support issues;
• roadmap decisions;
• design standards;
• architectural constraints;
• the actual code repository;
• analytics and experiment results;
• previous tickets and pull requests;
• the definition of success.

For larger work, this context also has to persist between sessions. A product does not reset every time a chat window closes. Neither can the agent working on it.

Persistent files give the work continuity. They let an agent retrieve the product intent, current state, prior decisions, and operating constraints instead of asking a human to reconstruct them every time.

Now the model is not being asked to write a generic feature spec. It is being asked to reason within the world of a specific product.

Goal + files + data + history + constraints
                    -> AI reasoning
                    -> Work that fits the situation

This is a much bigger improvement than learning a new prompt trick.

A capable model with weak context produces confident generalities. The same model with the right context can make a useful contribution to real work.

The lesson is simple:

Prompting helps you talk to AI. Context engineering helps AI understand the work.

But the human may still be carrying information back and forth. We have improved the intelligence without yet changing where it lives.

Harness engineering: put intelligence inside the workflow

Harness engineering is where the relationship changes.

Instead of leaving the product workflow to visit a chat, we place AI at a specific point inside the workflow.

For example, intelligence can be embedded into:

• product discovery synthesis;
• ticket refinement;
• architecture review;
• implementation planning;
• code generation;
• pull-request review;
• test planning;
• QA;
• release notes;
• incident analysis;
• customer feedback triage.

The model is no longer waiting in a separate room for someone to bring it a question. It has a defined job where the work is already happening.

Workflow step
    -> AI performs a bounded job
    -> Human reviews or decides
    -> Work moves to the next step

A harness does not have to cover the whole product lifecycle. It is usually better to start in one narrow place. The context should be available, the output easy to inspect, and the consequences understood.

A pull-request harness might read the change, the repository rules, the related issue, and the test results. It can flag likely problems and prepare a review. A human still owns the engineering decision.

The point is not to remove the engineer. The point is to stop making the engineer reconstruct the same context and perform the same mechanical translation every time.

This is where AI starts changing the economics of work. Intelligence is no longer something we consult. It becomes part of how the workflow moves.

It also changes the speed of feedback. When discovery synthesis, design exploration, implementation, testing, and review can happen closer together, the team no longer waits through the same long gaps between disciplines. The feedback loop contracts with the work.

Loop engineering: from assistance to execution

A harness gives AI a place in the workflow. A loop gives it responsibility for moving a bounded outcome from beginning to end.

To do that reliably, the AI needs more than context and access.

It needs to know:

• the outcome;
• the steps;
• the systems and tools involved;
• the skills it should apply;
• the records it should read and update;
• how to validate the work;
• how to verify the result;
• where human approval is required;
• what to do when the work does not pass.

The loop looks more like this:

New context or request
    -> Agent selects the right loop
    -> Loop gathers the required context
    -> Agent uses tools and skills
    -> Work is produced
    -> Work is validated
    -> Result is verified
    -> Human approves where required
    -> Outcome and learning are recorded

Consider a feature moving through the product lifecycle.

The outcome is not “write code.” The outcome is closer to “solve this user problem without breaking the product.”

That can mean understanding the request and finding related product decisions before touching the code. It can also mean proposing an implementation, writing the change, running tests, reviewing the result, preparing the release, and checking what happened afterward.

No single prompt can hold that together reliably. A loop can.

I came to loop engineering through a practical bottleneck: validation.

You should not trust AI output without validating it. At first, I did that validation myself. I inspected the work, judged it against the criteria, and gave the feedback back to the AI.

That works until the AI gets fast enough that human review becomes the slowest part of the system. I had removed one bottleneck and made myself the next one.

The way out was to make the validation process explicit. I could give the AI access to its output and define the judging criteria. I could also show it how to respond to failures. The AI could then inspect and improve its work before bringing the result to me.

That does not remove human accountability. It changes where human judgment is needed. Instead of manually catching every routine defect, the human designs the criteria, reviews the consequential choices, and checks whether the loop itself deserves trust.

Much of the engineering effort in an AI-native workflow goes into helping AI close its own loop.

This is also why the loudest version of autonomy is often the least useful one. The goal is not to let an agent do anything. The goal is to let it execute a known process within clear boundaries and prove that the work is ready for the next consequence.

Good loops make responsibility clearer, not fuzzier.

The Product Development Factory

The best example from my own work is a Product Development Factory I created.

It is a little meta. I used AI to build a system that uses AI to build software products with AI.

It is also a useful example because product development is my domain. I was not testing AI against an abstract workflow. I was applying it to the decisions and systems I had spent my career working inside.

The factory covers the end-to-end product path:

• what we want to achieve;
• why it is valuable;
• product and business requirements;
• design;
• architecture;
• code implementation and persistence;
• testing and validation;
• releases;
• customer outcomes.

The customer, in this case, is a company using AI to build a software product factory of its own.

Each client has a context folder that points to a Google Drive workspace. That workspace contains the client files and meeting transcripts. The loop regularly processes those materials so the latest client reality can enter the work without a human rebuilding the context for every run.

The loop compares what the client needs with the current infrastructure. It creates the tickets required to close the gap, develops the system, and validates the work. It also maintains a status file for the human operators. That file explains what has been completed and what the system still needs to finish the statement of work.

Client files + meeting transcripts
    -> Persistent client context
    -> Compare needs with current infrastructure
    -> Create and update tickets
    -> Develop and validate the system
    -> Maintain operator status file
    -> Surface what is still needed to complete the SOW

The important part is not that AI can generate code. Code is one step. The factory has to preserve the reason for the product and carry it into the requirements. It must move those requirements through design and architecture, coordinate changes across repositories, test what was built, and connect the release back to the outcome.

That is the difference between an AI coding tool and an AI-native product development system.

The collapse of the middle

Once work is organized this way, the shape of the organization begins to change.

A large amount of knowledge work sits in the middle between understanding reality and producing an outcome.

Service-as-software companies make this especially visible.

The first responsibility is understanding the client's reality. People meet with the client, learn what is happening, identify what is valuable, and bring that context into the company. That does not go away.

Traditionally, a large amount of processing follows. Someone turns the meetings into notes. A product or project manager extracts the meaningful parts. The new information is compared against current initiatives, planned work, and work already in motion.

Then the context has to enter the operating system of the company. It becomes tickets, epics, product requirements, business requirements, designs, specifications, and implementation plans. Meetings and ceremonies keep people aligned on what changed, what is moving, who owns it, and what happens next.

After that, people still have to do the work. They design, write specifications, make architecture decisions, implement the code, review it, test it, report status, deploy it, and communicate the result.

All of that is valuable. What makes it expensive is that the work and the orchestration both take time, and both have to be coordinated across people.

AI agents can now absorb much of that processing, execution, and orchestration. They can turn captured context into structured records and compare it with work in motion. They can update the right artifacts, execute bounded loops, validate the output, and report what changed.

The ceremonies, tickets, status updates, and handoffs were not the purpose of the company. They were the machinery required to keep human work coordinated. When agents can carry context and execute the loops, that machinery no longer has to sit between every stage.

The entire middle has collapsed.

I use collapsed deliberately. It does not mean every person disappears or that judgment no longer matters. It means the work no longer requires the same chain of humans to process, translate, coordinate, execute, validate, and report on context before an outcome can move.

The two remaining human layers are people who interface with reality and people who create the agents, systems, loops, harnesses, and skills that execute on that reality. Everything else has collapsed.

The Product Development Factory makes this concrete. Human operators bring in client reality and remain accountable for the statement of work. The factory carries that context through tickets, development, validation, and status. The human relay between those stages is no longer the operating requirement.

The future company has two increasingly valuable human layers.

The first layer interfaces with reality

These are the people closest to customers, users, physical operations, markets, trust, and new information.

They notice what changed. They understand what people mean, including the parts people cannot state cleanly. They identify value, ambiguity, risk, resistance, and opportunity. They bring reality into the company.

Nothing about AI removes the need for this work.

If anything, it makes the work more important. An agent system can process context quickly. It cannot rescue an organization that has stopped paying attention to reality.

The second layer turns context into outcomes with agents

These people know how to absorb and structure the incoming context. They know how to work with agents, improve loops, define boundaries, verify outputs, and keep the system connected to the goal.

They do not spend most of their time carrying information between tools. They design the path by which information becomes action.

Judgment, taste, and product direction remain human responsibilities, even when they are developed in collaboration with AI. Recognizing ambiguity and opportunity belongs here too. The agent can help us see more possibilities. The human still decides which future is worth building.

Trust and accountability remain the core value on both sides. That was true before AI and it remains true after AI. We are paid for what we can guarantee. People may care less about the exact combination of tools and people behind the work. They care deeply that they can trust and depend on the result.

Everything in this article is mainly about that second layer.

AI does not eliminate the need to understand reality. It eliminates much of the middle work required to translate reality into action.

That is the collapse of the middle.

Organize agents around outcomes first and systems second

There are many ways to organize agents. The best way I have found is to organize them around outcomes first and systems second.

An outcome agent understands what we are trying to achieve.

In the product lifecycle, that might be:

• solve a customer problem;
• ship a feature;
• improve onboarding;
• reduce churn;
• resolve an incident;
• improve product quality.

A system agent understands the environment where part of that outcome must be delivered.

In the SDLC, that might include:

• a frontend repository;
• a backend repository;
• a mobile application;
• a design system;
• analytics;
• CI/CD;
• product documentation;
• issue tracking;
• support data.

The outcome agent holds the goal and orchestrates the work. The system agents hold the deep context and boundaries of the systems that must change.

Product outcome
    -> Outcome agent
        -> Frontend system agent
        -> Backend system agent
        -> Design-system agent
        -> Analytics agent
        -> Release agent

The loops live within these boundaries. Proven processes become skills. Skills improve as the work is reviewed. Records preserve what happened, what changed, and what the organization learned.

This structure matters because a company does not need one giant agent with access to everything. It needs clear agents that know what they own, what they may change, and how they work together.

A personal agent or company brain is the final surface area

Once the context, harnesses, loops, skills, agents, records, and approval gates exist, a much simpler interface becomes possible.

For a personal agent, that interface might be Telegram, WhatsApp, SMS, voice, or a task interface.

For a company brain, it might be Slack, Microsoft Teams, or another shared chat surface.

The chat is not the important part. The routing behind it is.

One entry point
    -> Personal agent or company brain
    -> Route the request
    -> Select the outcome agent
    -> Coordinate the system agents
    -> Run the right loops and skills
    -> Validate and verify
    -> Return the outcome or request approval

A company brain is not a chatbot with access to company files.

It is one entry point into an operating system.

That system needs:

• clear routing;
• context boundaries;
• outcome agents;
• system agents;
• loops;
• skills;
• validation;
• verification;
• approval gates;
• substrates and records.

Without those pieces, the central chat may be convenient, but it is not yet a brain. It is another place to ask questions.

How to start

Do not begin by trying to build the whole company brain.

Start with one repeated outcome in the product lifecycle.

1. Name the outcome

Choose something more meaningful than “use AI in engineering.”

For example: reduce the time from a validated product decision to a reviewed implementation without lowering quality.

2. Map the current workflow

Write down how the work moves today. Include the people, systems, handoffs, records, decisions, and places where context is rebuilt.

3. Assemble the context

Identify what someone must know to perform the work well. That may include product intent, customer evidence, code context, constraints, past decisions, quality standards, and current state.

4. Add one harness

Place AI at one bounded step where the output is easy to inspect. Do not start with broad autonomy.

5. Turn the workflow into a loop

Define the steps, tools, skills, validation, verification, stop conditions, and approval gates.

6. Separate outcome ownership from system ownership

Name the agent or person responsible for the result. Then name the agents or people responsible for each system the outcome touches.

7. Record what the loop learns

Keep the decisions, corrections, outcomes, and updated skills somewhere both humans and agents can inspect. AI workflows need operational data, not just better prompts.

8. Add the common entry point last

Once routing has somewhere real to send the work, connect it to the chat surface your team already uses.

The interface should be the simplest part. The operating system behind it is the work.

The future of work is closer than it looks

The extraordinary AI outcomes people talk about are real. But they do not come from finding one perfect prompt or hiring a mysterious prompt engineer.

They come from a series of practical shifts.

First, we learn how to interact with intelligence. Then we give it the context around the work. Then we embed it into workflows. Then we engineer loops that can execute and verify outcomes. Finally, we make those loops accessible through a personal agent or company brain.

That is how AI stops being a tool we visit and becomes part of how work gets done.

It is also why I believe the middle of knowledge work has collapsed. The people closest to reality become more important. The people who build and operate the agent systems that turn context into outcomes become more important. The old human relay between them is no longer the default shape of the work.

I am writing this series for people in my network who want to understand that shift and put it to work. None of this requires us to pretend the hard parts have disappeared.

If you want guidance on getting started, email me at rick@datasaa.com. I would also be glad to compare notes on engineering agents, the SDLC, and the end-to-end product lifecycle.