AgentKit and agentic UX as a new layer of enterprise software
Agentic interfaces are changing how enterprise software looks and works. I break down what this means for architectural decisions and UX strategy.
When the first chatbots appeared in enterprise systems a few years ago, they were treated as a convenient interface over a knowledge base. You asked, you got an answer. That was a step forward compared to searching documentation, but it changed nothing fundamental.
The agentic approach is different. An agent does not just answer. It executes a sequence of actions, uses tools, talks to systems, makes intermediate decisions. The user sets a task - the agent completes it, rather than merely informing.
This changes how you need to think about enterprise software architecture.
What AgentKit is and why it matters
AgentKit is a concept - and a set of specific frameworks under this or similar names - that describes a standardised way to build agents: managing the tools they invoke, memory across sessions, task context, and the safety of their actions.
Without standardisation, every agent is its own kitchen with its own rules. With it, agents become components that can be combined, tested, and replaced.
For enterprise this matters: a company cannot manage a hundred unique agents with different access logic and different error handling. It needs a management layer.
What changes in UX
The traditional enterprise interface is a form, a table, a button. The user knows what the system does and controls it explicitly.
Agentic UX is a different contract. The user describes intent. The agent interprets it, plans steps, and executes. The user sees the result, not the full process.
This is more convenient for complex tasks. But it creates new problems:
- what to do if the agent did the wrong thing?
- how to explain to the user what happened?
- how to allow an action to be cancelled halfway through?
- how to provide an audit trail for compliance?
These are not technical footnotes. They are central questions of product design for agentic systems.
How this changes enterprise software architecture
When an agent calls tools, it calls APIs. The quality of a company's internal API design directly affects what agents can do. Good internal APIs become an asset.
Access control becomes more complex. An agent acts on behalf of a user but is not the user. You need a delegated permissions model that lets the agent do what the user is allowed to do - and nothing more.
Action logging becomes mandatory. When an agent does something in a system, it must be recorded with context: who gave the task, what action was taken, in what state.
Practical questions for managers
If your company is considering agentic systems, here are a few questions worth asking before starting:
- Which internal systems will the agent call, and are their APIs ready for this?
- How will the audit trail of agent actions be structured?
- How will a user be able to understand what the agent did and why?
- Which actions should the agent not be allowed to take without explicit confirmation?
- Who bears responsibility for an agent's mistake - the technical owner or the user who set the task?
Agentic UX is not a feature. It is an architectural layer. It needs to be treated as one.