Open any enterprise system and count the screens it takes to do one thing.
Take a blocked invoice. Someone has to find it, open it, check the purchase order, compare the price, look up the tolerance, add a note, and route it for approval. That is seven steps across three screens. The person started with one intention: pay this supplier the right amount, on time.
The software turned that intention into navigation.
Applications are how we organised software
Menus, modules, and transaction codes follow the vendor's data model. They exist because that was the practical way to build and sell large systems.
People adapted. We learned where things live. We trained new joiners on which screen comes after which. We wrote user manuals for work that is, at its core, a simple request.
None of that effort moves the business forward. It is the cost of talking to the system in the system's language.
What changes with agents
An agent can take the intention as the starting point.
"Clear the invoices blocked on a price mismatch below our tolerance." The agent works out which invoices qualify, checks each one against the purchase order and the rules, prepares the postings, and shows you what it plans to do.
The interface becomes three things:
- Say what you want done.
- Review what the system proposes.
- Approve it, or correct it.
Most of the screens go away, because most of the screens were there for navigation.
The interface gets smaller. The controls do not.
This is the part that gets missed. Building around intentions does not mean putting a chat box on top of an ERP.
When the interface shrinks, the system underneath has to carry more. It needs to know who is allowed to approve what. It needs rules it can check an answer against. It needs to keep a record of what was done and why.
So the model handles the understanding. A deterministic layer handles the control. The user sees less. The auditor sees everything.
Where to start
Pick one intention with a clear outcome and clear rules. Exception handling in finance operations is a good candidate, because the outcome is well defined and the rules already exist.
Then work through four questions:
- What states does this request move through?
- At which states does the model reason, and at which do rules decide?
- What does the system check before it acts?
- Where does a person approve?
Answer those and you have the outline of a system built around what people want done.
The application does not disappear. It moves into the background, where it belongs.
BruceLin Kithion is a consultant and solution architect who turns ideas into working products, with a focus on agentic AI.