Open questions

The questions the work is organised around

Each carries where I have got to so far. Two carry a claim specific enough that I can say what would prove it wrong, and those are marked. Three of them I expect to be working on for a long time.

Question 01 Open

How much autonomy can a system earn, and what does it have to show first?

The interesting cases are not the ones where a system does something harmless. They are the ones where an action moves money, sends something to a customer, changes a record other people depend on, or commits an organisation to a position.

Current position

Agent autonomy has to be earned. The more consequential the action, the more permissions, observability, determinism and reversibility it needs before it is allowed to happen without a person in the loop. Trust in software is built the way it is built anywhere else, by a record of behaviour under conditions where failure would have been visible.

I have taken this further than a position. What a system has to show first has a specific answer rather than a sentiment: identity before predictability, predictability before competence, competence before reliability, and alignment only after all of those. Each layer depends on the integrity of the ones beneath it. Alignment, which is usually treated as one thing, separates into intent and incentive, and incentive is the one nobody has solved.

There is a companion argument I find more practical. Control is not a feature to add if there is time: the ability to stop, reverse or override a consequential action is the error-correction loop for the system itself. A system without one cannot be corrected by the people it affects, however good its intentions are.

The part still genuinely open is that last layer. I can specify what evidence earns each of the layers below it. I cannot yet specify what evidence should convince you that a system's incentives are aligned with yours, and I do not think anyone else can either.

Falsifiable claim

Within three years I expect most serious enterprise agent products to ship substantially stronger permissions, approval boundaries, observability and reversal mechanisms than they do now. If instead the successful enterprise agents become broadly autonomous with little of that infrastructure, this was wrong.

Question 02 Open

If the interface of the future is not a chat box, what is it?

Chat became the default because it was the fastest way to expose a general model to a person. That is a distribution decision, not an interface decision.

Current position

Chat is good for ambiguity. Someone who does not yet know what they want, or cannot name it, is well served by a conversation. Chat is bad at nearly everything else: comparison, bulk editing, spatial arrangement, precise correction, reviewing something long, seeing state at a glance. The interface should emerge from the state of the work rather than being fixed in advance.

Part of the answer is that the surface should respond to runtime state rather than to a fixed category of user. The same person is fluent one day and lost the next because the case is unusual or the last three attempts failed. What varies is the situation, not the identity.

The open part is what generates it. A surface that appears because the work is in a particular state has to be assembled by something, and that something has to be predictable enough to trust and flexible enough to be worth having.

Question 03 Open

What is an agent actually bounded by?

The public conversation treats capability as a property of the model. Most of the failures I have seen were not reasoning failures.

Current position

Agentic systems are data systems. An agent is bounded by what it can sense, what it can remember, what it can understand about the domain it is acting in, and what it can verify after acting. Improve the model and a bounded agent stays bounded. Improve what it can sense and remember and the same model does more.

Data sits underneath the whole loop of sense, decide, act, show. It is not a stage in the loop. It is the floor.

There is a second boundary I did not see at first. An agent is also bounded by what survives the handoff. When control, context or a commitment crosses from one reasoning party to another, things get dropped that neither party is accountable for, and I now think that is where a great deal of the failure actually lives.

Question 04 Open

How much of enterprise software architecture is an artefact of a constraint that is disappearing?

Much of what we treat as the natural shape of business software was decided when computation was expensive, integration was painful, and every capability had to be packaged as a separate application with its own screens, its own data and its own login.

Current position

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.

That framing changes what you build. If the application is the end state you make a better application. If the application is an abstraction you ask what it was standing in for.

Question 05 Open

What changes between doing something once and doing it ten thousand times?

A demonstration and a production system look alike from the outside. They are not alike.

Current position

Once and ten thousand times are different engineering problems. Once tolerates a person watching, correcting, and quietly fixing the edge case. Ten thousand times requires that the edge case be handled, that failures are visible without anyone looking for them, and that the cost per run is something the business can carry. Most of the difficulty in agent products lives in that difference and very little of the public conversation does.

The published record supports this more than I expected when I first held the position. An early systematic evaluation of seven open-source multi-agent frameworks reported failure on 41 to 86.7 per cent of runs depending on the system and the task. Those are benchmark results rather than production telemetry, which nobody has published at scale yet. Its authors sort the failures into specification issues, inter-agent misalignment and task verification, and the first two together account for roughly four fifths of them.

Question 06 Open

Who owns the capability an organisation builds with AI?

Inside an enterprise the current pattern is that individuals each acquire an assistant, tune it to their own work, and take the result with them when they go.

Current position

AI inside an enterprise cannot remain a collection of individual assistants, and AI capability should belong to the organisation. When a consultant or an employee builds something that works, the organisation should still have it after they leave. That is a design commitment about where memory, permissions and workflows live, not a policy written after the fact.

Falsifiable claim

By 2029 I expect the enterprise conversation to move away from individual copilots as the primary model, with the important layer becoming shared AI environments carrying organisational context, permissions, workflows, memory and specialised workers. If by 2029 enterprise AI is still primarily employees individually talking to assistants with little persistent organisational state, this was wrong.

Question 07 Open

Will the application stop being the primary abstraction through which people think about computing?

People currently think in applications. You open one to do a thing. The thing and the container for the thing have been the same object for so long that they are hard to separate even in conversation.

Current position

I believe applications become implementation details, and that the application stops being the primary abstraction through which people think about computing. I hold this strongly.

The two predictions above carry dates because I can say what would falsify them and roughly when. This one I can argue for on structural grounds but not schedule, so it stands here without a year.

Question 08 Answered

Can a machine explain what it found, rather than only compute it?

This was the live question at Penser between 2014 and 2020. Sherlock could take a business question in plain English, resolve it into dimensions and measures, query the client's own database, run the analysis and the models, and gather insights. Across the datasets we deployed it against, in under 53 seconds.

The part it could not do well was say the finding back to a person in ordinary language. Natural language generation was the weak link in an otherwise working product. Stanford was attacking that problem through systematic learning, grammar, phrases and rules, and I believe Cambridge was too.

How it closed

Large language models took the other route. Trained on written text, they learned grammar by seeing it used rather than from a ruleset. Two ways to learn chess: from the rulebook, or by watching a great many games until the patterns arrive. Even grandmasters study older players and their openings, so the two are not clean opposites.

The first widely available model of that kind arrived in June 2020, three months after Penser closed and Vipani began. The question closed from a direction none of us was working in.

Why it is still listed

A closed question is not the same as a finished one. The next version of Sherlock my co-founder and I wanted is now possible, and analytics systems that interact with an end user are still lacking. The mechanism arrived. The product did not follow it automatically.

Question 09 Open

How do you serve genuine variety without the branches rotting?

Ashby's law says only variety can destroy variety. If people arrive in twenty meaningfully different states and a system has three responses, most of those states are handled badly no matter how good the three are.

Current position

The constraint is real and most quality effort ignores it, going into polishing existing responses rather than asking how many situations the system can actually tell apart. But serving more states means more branches, and branches rot. They drift out of sync, they get inconsistent, and eventually one of them is quietly wrong.

I do not have a general answer. What I am fairly sure of is that the choice has to be made explicitly rather than arrived at by accident, and that most systems have decided this without noticing they decided it.

Question 10 Open

Can a system adapt to someone without also being able to classify and control them?

Adapting to a person requires a model of that person. So does profiling them. It is the same machinery.

Current position

I do not think there is a technical solution to this, which is uncomfortable, because a technical solution is the kind I would know how to build. Conant and Ashby's result says a good regulator must contain a model of the system it regulates, so an adaptive system cannot avoid holding a model of the user.

That leaves governance as the distinction: whether the model is visible to the person, whether they can correct it, whether collection is proportionate, whether the model gates access to anything, and how long it is kept. I find this the least satisfying position I hold, because governance is exactly the property that erodes quietly and without anyone deciding to erode it.

Question 11 Open

When does successful delegation become dependence?

The point of a system taking work off someone is that they stop doing it. The consequence is that they may stop being able to.

Current position

Trust that a person cannot withdraw is not really trust. If they have lost the skill or the means to operate without the system, their reliance is no longer voluntary, and calling it trust flatters what is actually lock-in.

Where failure would be consequential, I think a system should preserve fallback capacity deliberately. That is a real cost with no visible benefit until the day it matters, which is why nothing does it. I do not know how to make that case in a way that survives a planning cycle.