The distance between intent and execution

Think about what actually happens when somebody at work decides to do something. They form an intention, usually in a single ordinary sentence. Hire a data analyst. Find out why the north region slipped last quarter. Buy the thing we agreed to buy. That sentence is the intent, and it is the only part of the process the person genuinely cares about.

Then the software arrives. The software does not accept the sentence. It accepts a sequence of operations, performed in the right order, in the right systems, with the right fields populated. The gap between the sentence and the sequence is where a person's day goes.

I have spent most of my working life on that gap without initially recognising it as one thing. From the outside it looks like several separate problems. Analytics is slow. Procurement is bureaucratic. Enterprise tools are hostile. Those look like different complaints until you notice that each of them is the same complaint with different vocabulary. Somebody knew what they wanted and the system made them assemble it.

The analytics case, and why it was a good place to start

Analytics is a clean version of the problem because the intent is unusually well formed. When a business person wants to know something, they can generally say it. Which products are dragging margin. Whether the campaign moved anything. What changed in the north region.

What happened next, in most organisations, was a chain of translation. The business person described the question to somebody technical. That person interpreted it, decided which tables held the relevant facts, wrote the query, ran it, looked at the result, decided whether it answered the question as asked or as meant, and produced something readable. If the answer raised a new question, and it usually did, the chain ran again.

Three to four weeks. That was the honest duration, not for a slow team, but for a real request moving through a real organisation and coming back. Most of that time was not computation. It was queueing, clarification, and the several rounds of interpretation between the person who wanted to know and the person who could find out.

At Penser we built a product called Sherlock to remove the chain. A user typed a business question in plain English. Natural language processing understood it and extracted client-specific modalities, which is a dry way of saying it knew that in retail these words are products, in insurance these words are policies, and in marketing these words are campaign names. Those resolved into dimensions and measures, which went to a query engine that ran against the client's own database. The analysis ran, the machine learning models ran, insights were gathered, and reports and insights came back.

Three to four weeks became 53 seconds. Under 53 seconds, regardless of the size of the data.

That number is the strongest piece of evidence I have about anything, and I want to be careful about what it proves.

What 53 seconds proved, and what it did not

It proved that the chain of translation was not necessary. The intermediate steps existed because building them into software had been hard, not because the work fundamentally required a person at each junction. Remove them and nothing important is lost.

It also proved something less obvious about which part is valuable. Running the query fast was the visible achievement. Insight generation was the part that mattered most. Producing a table quickly is a benchmark. Telling somebody which three rows of that table deserve their attention this week is a product. That was the kicker, and it was much harder than the speed.

We connected Google Assistant to Sherlock, so somebody could ask out loud and the assistant simply answered. It worked. It is worth noticing that once the underlying system could genuinely answer, the interface almost stopped mattering. The voice assistant was not the achievement. It was a thin surface over a system that had already done the difficult part.

What 53 seconds did not prove is that the distance had closed. Somebody still had to know which question to ask. Somebody still had to decide what to do once the answer arrived. And somebody still had to carry out whatever that decision implied, in some other system, by hand.

We had compressed one segment of the path from intent to execution, and we had compressed it dramatically. We had not connected the segment to the ones on either side of it. The person's actual intent was rarely to know something. It was to fix something, and knowing was a step on the way.

That sounds like a small distinction. I don't think it is. It is the difference between building a very good tool and building something that takes responsibility for an outcome.

Operating software versus instructing it

There is a useful line between two relationships a person can have with a system.

In the first, the person operates the software. They hold the plan, they know the sequence, and the software provides the controls. The system is a set of levers. Its correctness is measured by whether the levers do what they say. Whether the right levers were pulled in the right order is entirely the operator's problem.

In the second, the person instructs the software. They state an outcome. The system works out the sequence, carries it out, and reports back. Correctness now includes whether the outcome was achieved, which is a much larger claim to make.

Almost all enterprise software sits in the first category while marketing itself as though it belonged in the second. It offers workflows, meaning fixed sequences that a person still has to select, populate and advance. A workflow is not instruction. It is operation with better signage.

The move from operating to instructing is not a user interface change. It requires the system to hold a model of what the person is trying to achieve, to know what steps that implies in this particular organisation, to have permission to take those steps, and to be able to say afterwards what it did. That is four separate capabilities, and most products that claim to be in the second category have implemented one of them.

The hiring example

Here is the shape of it in a case everybody has lived through.

A manager decides to hire a data analyst. That is the intent, and it is complete. Everything the organisation needs to know is contained in that sentence plus a small amount of context the manager already holds in their head.

Here is what happens instead.

Consider what those twelve fields are. Department, cost centre, grade, reporting line, employment type, location, budgeted salary band, start date, headcount justification, replacement or incremental, job family, approval chain. The manager knows perhaps three of them from the intent itself. The rest they either look up, guess, or copy from the last requisition they filed and hope it still applies.

Every one of those fields exists for a real reason. Finance needs the cost centre. Compliance needs the employment type. The approval chain needs to exist so that hiring is not unilateral. The fields are not stupid. The situation is stupid, because a system that already knows the manager's department, cost centre, reporting line, location and grade band is asking the manager to tell it those things again, as a condition of accepting an instruction it could otherwise have carried out.

And the approval step is doing real work. Somebody senior should look at a new headcount. But the thing they are approving is a form, filled in by a person who was guessing at half of it, rather than the decision itself.

The distance between hire a data analyst and a submitted requisition is roughly twenty minutes of an experienced person's time, most of which is spent supplying information the system already holds. Multiply by every intent that person forms in a week.

Autonomy without control is not the answer

The obvious response is to let a system do all of it. State the intent, let the machine fill the form, submit it, chase the approval, post the role, screen the applications.

That answer is wrong in an important way, and the way it is wrong is instructive.

The manager does not want to be removed from hiring. They want to be removed from data entry. Those are different requests and conflating them produces systems that people quietly refuse to use. If the system creates a requisition the manager did not see, at a grade they would not have chosen, and it goes for approval with their name on it, they have not been helped. They have been exposed.

The question is not how much a system can do. It is how much it can do while leaving the person's understanding and control intact.

This is what I mean by autonomy being earned. The permission a system holds should track the consequence of the action. Drafting the requisition is low consequence and easily reversed. Submitting it into an approval chain is higher, because other people's attention is now committed. Posting the role publicly is higher still, because it is visible outside the organisation and cannot be quietly undone.

Each of those steps needs a different level of permission, a different amount of observability, and a different guarantee about reversibility. A system that treats all three identically is either too timid to be useful or too bold to be trusted, and usually it is both at different moments.

Which is why the loop has four steps rather than three. Sense what is happening and what needs attention. Decide what should happen. Act through the right workflow. Show the work and the outcome back to the person. The fourth is the one that gets dropped, because it adds no visible capability. It is also the only one that lets a person stay in charge of something they are no longer doing by hand.

Once versus ten thousand times

Everything above is achievable once. A demonstration of an agent creating a requisition from a sentence is not difficult to build and looks impressive.

Once and ten thousand times are different engineering problems, and the gap between them is where most agent products die.

Doing something once tolerates a person watching. When the model misreads the grade band, somebody notices and corrects it. When the department has an unusual approval chain, somebody handles it manually. When the run costs more than expected, nobody is counting.

At ten thousand runs, none of that holds. The unusual approval chain is not an exception, it is four percent of cases, which is four hundred incidents. Nobody is watching, so the misread grade band propagates until somebody downstream notices a pattern in the payroll data. The cost per run, which was irrelevant in the demonstration, is now a line item that has to justify itself against the labour it replaced.

So the real requirements are unglamorous. The edge case has to be handled rather than absorbed by a human. Failures have to be visible without anyone actively looking for them. The cost per run has to be something the business can carry at volume. Actions have to be attributable and reversible after the fact, because at that scale you will need to undo things in bulk.

Very little of the public conversation about agents is about any of this. Almost all of the difficulty is.

The case against the chat box

Which brings me to the interface, because the current default is actively working against everything above.

Chat became the standard way to reach a model because it was the fastest way to expose general capability to a person. That was a distribution decision and a good one. It has been mistaken for an interface decision, which it is not.

Chat is genuinely excellent at ambiguity. Somebody who does not yet know what they want, or cannot name it, is well served by a conversation that helps them arrive at it. That is a real and valuable case.

Chat is bad at nearly everything else. It is bad at comparison, because two things cannot be held side by side in a scrolling transcript. It is bad at bulk editing, because there is no way to select. It is bad at precise correction, because the only tool is a description of the change rather than the change itself. It is bad at reviewing anything long. It is bad at showing state, which matters enormously, because showing the work back is the step that keeps a person in control.

Consider the hiring case in a chat window. The system drafts a requisition and describes it in prose. The manager wants to change the grade band and the location, keep everything else, and see how this compares to the last three requisitions from their team. Every one of those is awkward to express in a sentence and trivial in a surface built for it.

The interface should emerge from the state of the work. When the work is ambiguous, a conversation is right. When the work is a draft awaiting review, a document with the changed fields marked is right. When the work is a decision between options, a comparison is right. When the work is a long-running process, a status view is right. Fixing one of these in advance and applying it to all of them is the mistake, and chat happens to be the one that got fixed.

What an application becomes responsible for

Follow this through and the shape of the thing changes.

Today an application is a container. It holds a set of screens, a data model, a login, and a set of operations a person can perform. Its responsibility ends at correctness of those operations. Whether the person achieved anything is outside its remit.

If a system accepts intent rather than operations, its responsibilities expand. It becomes responsible for understanding what was meant, which requires a model of the person and their world rather than a parse of the sentence. It becomes responsible for knowing what steps the intent implies here, which is organisational knowledge rather than product knowledge. It becomes responsible for holding permission appropriate to each step. It becomes responsible for showing what it did in a form the person can check and correct. And it becomes responsible for the outcome, not merely the operations.

Those are not features you add to an application. They are a different object with a different boundary, and most of the capability lives underneath the level where applications currently sit.

Which is why I think most enterprise software architecture is an artefact of a constraint that is disappearing. Procurement is an application. Data is core infrastructure. AI and agents are the current enabling technology. Reducing the distance between intent and execution is the larger problem underneath all of them. Applications are an interface abstraction, not the end state.

I believe the application stops being the primary abstraction through which people think about computing. I hold that strongly and I will not put a year on it, because attaching a date to a belief I hold on structural grounds rather than evidence would turn a genuine conviction into theatre.

What I will say is narrower and testable. The distance between intent and execution is the thing worth working on. It is not a speed problem, which is what I thought when 53 seconds felt like the answer. It is a problem about what a system knows, what it is permitted to do, and what it shows you afterwards. Get those three right and the sentence a person says in the first place becomes enough.