The Atlassian Friend #8 — Agentic UX: When Intent Replaces the Interface

[#1]

For the last two weeks, I have been working on a small proof of concept around Slack, Rovo, Forge, Jira Service Management and Assets.

But this article is not really about the POC.

The POC is simply where the idea became visible.

I started with a problem that sounded quite simple.

We already had web-based service experiences.

We already had forms, workflows, automation and all the usual structures we build around enterprise services.

And we wanted to make those services easier to consume from Slack.

So the obvious question was:

How do we add AI to the experience we already have?

At first, that sounded completely reasonable.

Then I started building.

And the problems started appearing.

Not one big problem.

Lots of small ones.

And, looking back, that was probably the useful part.

Every problem had another assumption underneath it

The AI sometimes needed information that existed only because a human had already followed a particular path through an interface.

Some logic assumed that the employee had already made choices that were really part of how we had designed the service.

Some information was being requested because the interface expected it, even when another system already knew it.

Sometimes the AI could understand roughly what somebody wanted, but not with enough certainty to safely act.

We would solve one problem.

Then another assumption appeared underneath it.

At some point I noticed that I was spending a lot of time trying to make AI understand how our existing experience worked.

And I started wondering whether that was the wrong problem.

The question changed from:

How do I make AI work with this interface?

to:

Why does AI need to understand the interface at all?

That question changed almost everything.

Maybe we had designed around the wrong thing

Most enterprise service experiences are designed around navigation.

The employee needs something.

They open a portal.

They find where they think the service lives.

They choose something that represents what they need.

They understand a form.

They provide the requested information.

They submit it.

There is nothing inherently wrong with this.

It works.

We have been designing systems this way for years.

But once I started looking at it from an AI perspective, something began to bother me.

The employee is effectively navigating part of our architecture.

They need to understand how we have organised the service.

They need to recognise the terminology.

They need to make the right choices.

They need to translate what they actually want into the structure we built.

And because humans have learned to do that, we tend to assume AI should learn to do it too.

That started to feel backwards.

The employee does not really want a form.

They do not want a page.

They do not want to understand our service structure.

They want something.

Access.

Help.

A change.

An approval.

A problem solved.

The rest is our implementation.

That led me to one of the first principles that came out of the POC:

The form is an interface, not the service.

Once I started thinking about it that way, putting AI on top of the existing experience became much less interesting.

Because if the interface is not the service, why are we teaching AI to navigate the interface?

What if intent came first?

Imagine an employee writes:

“I need access to a tool for my new project.”

That is probably all they actually know.

And maybe that is all they should need to know.

A traditional experience asks them to take that intention and navigate until they find the right representation of it.

But once you stop making the interface the centre of the experience, another model becomes possible.

That was the actual shift for me.

In a traditional experience:

The user navigates the architecture.

In an agentic experience:

The user expresses intent and the architecture resolves the path.

That sounds like a small distinction.

I do not think it is.

It changes where the complexity belongs.

The architecture should absorb complexity

This may be the part I keep coming back to.

A lot of enterprise UX is really the user being exposed to architectural decisions.

We decided how services are grouped.

We decided which information is required.

We decided which system owns which part of the process.

We decided which workflow executes next.

Then we expose part of that structure through an interface and ask the employee to navigate it correctly.

What happens if we reverse that responsibility?

The user expresses what they need.

The architecture understands enough of the service landscape to resolve the rest.

That does not mean hiding governance.

It does not mean making everything autonomous.

And it definitely does not mean letting an AI model improvise its way through enterprise systems.

It means moving complexity away from the employee where we reasonably can.

That distinction became very important in the POC.

AI handles ambiguity. Architecture handles certainty.

Once intent becomes the starting point, AI becomes extremely useful.

People do not speak in fields.

They do not describe problems using our internal taxonomy.

They omit things.

They use different words for the same idea.

They change languages.

They say things that could mean more than one thing.

That is ambiguity.

AI is good at that.

But once the ambiguity has been resolved, I want the system to become progressively less probabilistic.

That became probably the central architectural principle of the experiment:

AI handles ambiguity. Architecture handles certainty.

AI can interpret.

AI can summarise.

AI can recognise likely intent.

AI can ask a clarification question.

But validation, permissions, business rules, mappings, execution and auditability should increasingly belong to deterministic architecture.

There is a boundary.

And I think that boundary matters a lot in enterprise AI.

Asking a question is not a failure

This also changed how I thought about AI confidence.

Imagine the employee says something that could reasonably mean two different things.

One approach is:

I really do not like that pattern.

Especially when execution has consequences.

The alternative is:

If the system does not know enough, it can ask.

Not five questions.

Not the entire form.

Just the question needed to remove the ambiguity.

Then continue.

A clarification question is not AI failing.

Sometimes it is AI behaving responsibly.

And this became one of the most useful lessons from the POC.

Conversation in. Structured intent out.

Another way I started thinking about the architecture was this:

Conversation in. Structured intent out.

The conversation should not be the end product.

The objective is not to generate a clever response.

The objective is to progressively transform something human and ambiguous into something structured enough for enterprise architecture to safely act on.

That, for me, is much closer to the interesting part of enterprise AI.

Not another chatbot.

Not another assistant sitting next to an existing interface.

A way of translating human intent into governed action.

Then I started questioning Forms

This was one of the moments where the POC changed my thinking again.

A very natural approach when bringing an existing service experience into Slack is to reproduce the form there.

It makes sense.

Take the questions.

Recreate them.

Collect the answers.

Send them to the backend.

Done.

But then I started asking:

Why are we recreating the interface?

The service already has a structured definition somewhere.

The architecture already knows what information is required.

So perhaps the better question is not:

“How do I reproduce this form in Slack?”

but:

“How can the architecture understand what this service requires?”

That changes the role of the form.

The form can still be extremely important.

But it does not necessarily need to be the experience.

It can become a source of structure that the architecture consumes.

And then something much more interesting becomes possible.

Suppose a service requires several pieces of information.

Some may already be contained in what the employee said.

Some may already be known from enterprise context.

Some may be inferable.

Only the missing pieces need to become questions.

That led to another principle:

Do not ask the employee for information the architecture already knows.

It sounds like a UX improvement.

I think it is an architectural one.

Context changes the conversation

That naturally led to identity and context.

If someone starts interacting from a collaboration platform, we already have some idea of who they are.

If that identity can be connected to enterprise context, the experience changes significantly.

That context might include relationships, devices, applications, ownership or other information the organisation has chosen to model.

The exact information is not really the point.

The important thing is what the architecture can now avoid asking.

Imagine someone says:

“My laptop is having problems.”

A traditional interaction might immediately ask:

“Please provide the serial number.”

But if the architecture already knows which device belongs to that employee, maybe the better question is:

“Are you referring to your laptop?”

That looks like a very small difference.

But I think it represents a big change.

In the first model, the employee translates their world into information the system understands.

In the second, the architecture uses context to understand the employee.

Context can work in the opposite direction too

This was another thing I did not initially expect.

The relationship does not have to start with an employee conversation.

It can start with a business event.

Something needs approval.

Something is approaching a service threshold.

Somebody needs to be notified.

The architecture can resolve the relevant person and the appropriate interaction channel.

At that point, identity mapping stopped looking like a feature of one POC.

It started looking like a reusable platform capability.

And enterprise context stopped looking like background data.

It became part of the experience.

This stopped being a chatbot problem

Somewhere during those two weeks, I realised I was not really designing a chatbot anymore.

The conversation was just the first layer.

The interesting part was everything that happened after it.

The employee expresses something naturally.

AI interprets it.

If necessary, it clarifies.

Context helps resolve what the employee means.

The architecture determines what is still missing.

The employee confirms when appropriate.

Then deterministic orchestration takes over.

The governed system records and manages the result.

That changed the objective of the POC.

The goal stopped being:

“Give employees an AI chatbot.”

It became closer to:

Let employees express what they need naturally, then let the architecture determine how that intention becomes a safe, contextual and governed enterprise action.

That is much more interesting to me.

Slack-first changed meaning too

The same thing happened with Slack-first.

Initially, it is very easy to interpret Slack-first as:

create something in another system from Slack.

Useful.

But I do not think that is enough.

If Slack is really part of the employee experience, the service interaction should be able to continue there.

The initial request.

Clarifications.

Confirmation.

Updates.

Conversation.

Relevant actions.

The employee should not necessarily care that several systems are collaborating underneath.

From their perspective, they asked for something.

The service continues.

That led me to another distinction:

The employee experience and the system-of-record experience do not need to be the same experience.

A governed backend can remain absolutely essential without being the first thing the employee needs to see.

That is not hiding the backend.

It is allowing each component to do what it is actually good at.

The responsibilities became clearer

Once I stopped treating the interface as the centre of the architecture, the responsibilities of the individual components also became much clearer.

Slack could handle interaction.

Rovo could help with ambiguity and language.

Assets could provide enterprise context.

Forge could orchestrate deterministic execution.

Jira Service Management could remain responsible for governance, workflow, traceability, SLA, exceptions and human intervention.

That separation felt much cleaner.

Slack-first does not mean Slack owns the process.

Agentic does not mean AI owns the process.

And JSM does not become less important simply because the employee sees less of it.

In some ways, it becomes more focused on the things we actually need it to guarantee.

Then I found the name

This is an important part of the story for me.

I did not start this experiment by researching Agentic UX.

I did not begin with a framework and try to implement it.

I was trying to solve the problem.

That was it.

I kept asking questions.

Why should the employee understand our internal structure?

Why should AI reproduce the navigation patterns we designed for humans?

Why should we recreate an interface in another interface?

Why should we ask somebody for information we already know?

Why should AI guess when it can clarify?

Why should probabilistic reasoning continue all the way into deterministic execution?

One by one, those questions changed the architecture.

Eventually, I started recognising that the direction I had reached independently had a lot in common with what is increasingly being described as Agentic UX.

I arrived there from the problem, not from the terminology.

And I actually like that.

Because the term is useful.

But the term is not the important part.

The important part is the shift in responsibility.

From:

User understands the system

to:

System understands the user’s intent

From:

User navigates complexity

to:

Architecture absorbs complexity

From:

AI added on top of an interface

to:

AI resolving ambiguity inside the experience

And finally:

Architecture taking over when certainty matters

That is the paradigm shift I find interesting.

The POC came afterwards

This is why I see the POC differently now.

It is not the idea.

It is evidence.

I wanted to know whether this way of thinking would survive contact with a real enterprise service environment.

Could somebody begin naturally?

Could the system understand intent?

Could it identify when it did not know enough?

Could it clarify instead of guessing?

Could it use known context?

Could it avoid asking unnecessary questions?

Could it ask for explicit confirmation before acting?

Could deterministic architecture take over after ambiguity had been resolved?

Could the interaction continue while the governed service record remained somewhere else?

The POC exists to test those questions.

And so far, the interesting result is not that it can create something in Jira Service Management.

We already know software can create things in Jira.

The interesting result is that the employee does not necessarily need to navigate the structure through which we traditionally expose the service.

That is what I wanted to validate.

This is still only a POC

I think that distinction matters.

This is not a finished platform.

There are still many questions.

Security.

Permissions.

Governance.

Observability.

Error handling.

Sensitive actions.

Human intervention.

Context boundaries.

Scale.

When to let AI decide.

When not to.

And probably several edge cases I have not found yet.

But that is exactly why I like building POCs.

A good POC does not have to prove that every production problem has already been solved.

It needs to challenge an assumption.

And then tell you whether that assumption is worth challenging further.

This one did that for me.

Because I started those two weeks asking:

How do we add AI to the interface we already have?

I am ending them asking a very different question:

If the user expresses an intent, what does the architecture need in order to understand it, contextualise it and safely act on it?

I think that is a better question.

Because once you ask it, the interface stops being the architecture.

It becomes one way of accessing the service.

The breakthrough was not a better prompt.

It was not a particular model.

It was not Slack.

It was not one clever integration.

It was changing what sat at the centre of the design.

We did not solve the problem by teaching AI how to use our interface.

We started solving it by removing the interface from the centre of the architecture.

And perhaps that is where Agentic UX really starts.

Below the interface.

About The Atlassian Friend

The Atlassian Friend is my personal series about the things I keep discovering while working with the Atlassian ecosystem.

Sometimes that means architecture. Sometimes service management. Sometimes AI. Sometimes just questioning why we do something in a particular way.

It is not documentation, and it is not intended to present one “correct” way of doing things.

It is simply me thinking out loud, sharing experiments, ideas and lessons learned along the way.