AI-Native Companies Design Work, Not Software

Enterprise architecture has always mirrored the technology of its time.

When computers could only process transactions, we designed transaction systems. As software became more sophisticated, we organised it into applications. Service-oriented architecture taught us to separate responsibilities. Microservices encouraged us to build smaller, independently deployable services. Cloud platforms changed how software was delivered, but not how we thought about it. Throughout every one of these changes, one assumption quietly remained intact. Software existed to support people.

That assumption influenced far more than technology. It shaped how organisations worked. Business capabilities became applications. Applications became components. Components became user interfaces. Success was measured by whether people could perform their jobs more efficiently. The software was the workplace.

Artificial intelligence challenges that assumption in a way previous technology shifts never did.

In a recent article, we argued that AI replaces tasks rather than people. At first glance, that feels like a discussion about automation. The more we explored it, however, the more we realised it raises a much bigger question.

If software increasingly performs the work, rather than simply helping people perform it, why are we still designing organisations as though people sit at the centre of every system?

That question has been surprisingly difficult to answer because our architectural methods were never designed for this world.

Today, an enterprise architecture journey typically begins with strategy and business requirements. Architects identify business capabilities, define applications, allocate responsibilities to systems and eventually decompose those systems into components and services. Designers create user experiences, developers build software and, after deployment, the business starts measuring whether the expected outcomes have been achieved.

There is nothing fundamentally wrong with this approach. It is simply optimised for organisations where applications are the primary place in which work happens.

An AI-native organisation operates differently.

The AI does not care whether information comes from an ERP platform, a CRM system or a document repository. It does not navigate menus, complete forms or search dashboards. It needs an objective, reliable information, appropriate authority and clear boundaries within which to act. That changes the architectural question completely.

Instead of asking which systems do we need, we first need to ask what work needs to be performed.

This may appear to be a small change in wording. I believe it represents one of the most significant shifts enterprise architecture has experienced in decades.

Work has always existed, yet we have rarely treated it as the primary architectural artefact. Business processes describe how value flows through an organisation. Capabilities describe what an organisation must be able to do. Applications describe the technology that supports those capabilities. Somewhere between those layers sits the actual work performed every day by employees, contractors, suppliers and increasingly AI.

We have traditionally skipped over that layer because people naturally filled the gaps.

AI no longer does.

That realisation led us to a simple conclusion. AI-native organisations need another architectural layer between Business Architecture and Solution Architecture. We have started calling it Task Architecture.

The name is less important than the thinking behind it.

Rather than decomposing an organisation into applications, a Task Architecture decomposes it into atomic units of work. Each task exists for one purpose. It consumes defined information, produces defined outputs and creates measurable business value. Only after the work has been defined do we decide how it should be implemented.

Some tasks naturally become deterministic software because they demand consistency, transactional integrity or strict compliance. Others become AI agents because they require reasoning, interpretation or judgement. A small number deliberately remain with people because governance or legislation requires human review.

Notice what has changed.

Applications are no longer the primary design decision. They are one possible implementation.

This distinction becomes even more important when organisations begin their AI transformation.

Many organisations are currently asking where AI can be added to existing applications. That is a sensible question if the goal is incremental improvement. It is the wrong question if the goal is becoming AI-native.

An AI-native organisation does not begin by asking where AI fits.

It begins by asking how the work itself should be organised.

That difference affects almost every architectural decision that follows.

It also changes how we think about measurement.

Most organisations build dashboards after software has been delivered. Technical teams monitor infrastructure. Business analysts create reports. Executives receive KPIs weeks or months after implementation. Measurement is often disconnected from the architecture that produced it.

That approach becomes increasingly difficult when hundreds or thousands of AI-driven tasks continuously perform work across the organisation.

If a task exists to verify a customer’s identity, the organisation already knows how success should be measured. If another task creates a new company, its business outcomes are equally clear. Every task should therefore define its own business KPIs before implementation begins. Those measures naturally aggregate into Task Groups, business capabilities and ultimately strategic organisational objectives.

Observability stops being an operational activity. It becomes part of architecture itself.

Our own experiments quickly revealed another practical challenge. Large organisations perform thousands of tasks. Trying to identify them all at once is almost impossible. We found it far easier to model work from the perspective of a particular role or responsibility. We refer to these perspectives as Task Scopes. A Customer Success Manager, for example, provides a natural starting point for discovering every task involved in onboarding and supporting customers. Those tasks can then be grouped, refined and eventually assigned to software, AI or human review.

The accompanying model illustrates this thinking. It is not intended to replace BPMN, ArchiMate or other established techniques. Those remain valuable. Instead, it attempts to describe something those methods rarely make explicit: the work itself.

Whether this particular model survives is almost beside the point.

What matters is recognising that AI-native organisations need to be designed differently from organisations where humans perform most operational work. Continuing to optimise applications while AI increasingly performs the work feels remarkably similar to optimising horse-drawn carriages after the arrival of the motor car. The existing designs still function, but they no longer describe the problem that needs solving.

Every major technology shift has forced architects to rethink their assumptions. Cloud changed where software runs. Microservices changed how software is built. AI changes something much more fundamental.

It changes who performs the work.

If that observation proves correct, then the future of enterprise architecture may not be defined by better systems or smarter agents. It may be defined by something far simpler and far more challenging.

Learning to design work before we design software. This article was created by people. We have used artificial intelligence (AI) to help articulate our message and refine the text. AI was employed as a tool to assist with structuring, identifying grammatical and spelling errors, and improving readability. The final document has been carefully reviewed and approved by our team.

© Centipod B.V., 2026