UI-layer vs API-layer: a pattern in AI agent building I’m seeing in enterprise tooling — does it map to yours?

A pattern I’ve been living inside for eight months. Putting a name to it. Asking the community: does this map to your experience?

Human ↔ AI: The two channels

I want to start with something I haven’t fully figured out yet.

We use GitHub Copilot. Have been for eight months now. And somewhere along the way, our drawer filled up — custom agents for spec-driven development, prompts for test generation, instruction files for raising Jira tickets, Confluence wiki templates, a service investigator agent wired to Kubernetes and Grafana across our microservices.

Real tools. Real productivity gains. I’m not complaining about any of it.😅

But I kept noticing something I couldn’t quite name. Some of what we were building with AI felt like one kind of thing. And some of it felt like a completely different kind of thing. And we were treating them the same way — same discipline, same storage, same ownership model — which might be exactly why our drawer keeps filling up without ever quite emptying.

I’ve been turning this over for a while. I think I’ve found a frame. I want to share it — not to declare it settled, but to ask people who are navigating the same terrain: does this resonate with what you’re seeing in your organisations?

What I keep observing in our own workflow

Looking at how our team actually uses AI day to day, everything seems to fall into one of two modes.

Some of it requires a human in the seat, making judgment calls in real time. The AI helps them go faster, draft better, miss fewer things — but the human is the decision-maker at every step.

Some of it runs without a human watching at all. A trigger fires, a workflow begins, outputs get produced and acted on. The human designed the system. The system runs it.

Same tools. Same underlying models. Completely different relationship between human and AI.

I’ve been reaching for words to describe this split. For lack of a better term, I’ve started calling them UI-layer AI and API-layer AI — not because the underlying technology is necessarily different, but because the relationship between human and AI is completely different. One mode keeps the human as the decision-maker at every step. The other treats the human as the architect who designs the system upstream, then steps back.

I don’t know if those are the right words. But having words at all has helped my team think more clearly about which AI investments belong where — and it’s opened conversations we weren’t having before.

What I’m genuinely curious about is whether this distinction maps to how other enterprise leaders are thinking about it. Or whether I’m drawing a line where there isn’t really one.

The UI-layer side of our workflow — human always in the seat

Let me make this concrete with our real examples, because abstraction is what kills most of these conversations.

Spec-driven development. When we’re building a new feature, we prompt Copilot or Claude with the business requirement, the service context, and the constraints. The model generates a first-cut spec. Then the real work starts: questioning the assumptions it made, adding the context only we hold, catching the edge cases that require knowing our architecture. The AI produces volume. The engineer produces judgment. Both are necessary. Neither is sufficient alone.

Test generation. Our QA engineers now start with a prompt rather than a blank test file. Describe the service behaviour, the known failure modes, the happy path — and ask the model for edge cases. The model proposes twenty scenarios. A good QA engineer keeps twelve, rewrites four, deletes the rest, and adds three it missed entirely. The engineer’s judgment is what makes the output useful rather than just comprehensive.

Jira ticket creation. This one surprised me most. Prompting Copilot with raw incident context — what happened, which service, expected versus actual behaviour — and asking it to generate a structured bug report produces noticeably better tickets than writing from scratch. The discipline of prompting forces you to articulate the problem clearly. The model’s output gives you something to edit rather than a blank field to fill. But the framing, the severity, the backstory — that still comes from the person who lived the incident.

Confluence wiki pages. We use Atlassian MCPs to feed in service context — architecture, dependencies, runbook notes — and ask the model to generate a structured wiki page. The output is a solid 70% draft. But someone still has to know whether it’s accurate. You cannot outsource that judgment to the model, and I’m not sure you’d want to.

In all of these cases, the human is present at the moment of consequence. The model assists. The human decides. That’s what I mean by UI-layer AI — and what I’m curious about is whether this feels like a coherent category to other practitioners, or whether I’m forcing a pattern onto things that are just… different tasks.

The API-layer side — where the human designs but doesn’t execute

Then there’s the other mode, and this is where I find myself with more questions than answers.

The service investigator. This is the most interesting thing we’ve built. We have an agent wired to Kubernetes and Grafana MCPs across our microservices. When something goes wrong — a pod in crash loop, an anomalous spike, a cascading failure — the investigator pulls relevant logs, correlates events across services, and surfaces a summary of what’s happening and where to look first.

No human is driving this in real time. The agent navigates the MCP connections, queries Grafana, pulls Kubernetes state, and assembles the picture. The on-call engineer receives a briefing rather than raw chaos.

This feels qualitatively different from spec-driven or test generation work. The inputs are structured — metrics, logs, pod states. The workflow is repeatable. The human’s role shifted from executor to architect: we designed the system, and now the system runs it. That’s what I mean by API-layer AI.

What I’m genuinely not sure about: are more of our workflows candidates for this mode than we’ve recognised? Or is the investigator a special case because the inputs happened to be structured enough to make autonomous operation sensible? This is the question I’d most like to hear other teams’ answers to.

Why I think this split maps onto something older

Here’s the broader observation I keep coming back to — and I want to be clear this is a hypothesis, not a conclusion.

The pre-build phases of the SDLC — discovery, design, spec writing, development — have always been human-intensive. Someone has to decide what to build and how. Figma, Confluence, IDEs — all of them surface information and handle mechanics so humans can decide faster. The human judgment was always the point.

The post-build phases — test automation, deployment pipelines, monitoring, incident response — have always been about encoding a good decision once and having it run reliably without anyone present. Jenkins pipelines, Grafana alerts, automated test suites. The human’s contribution was upstream, in the design.

What I’m observing is that AI seems to be landing on both sides of this existing split. UI-layer AI is finding its home in the pre-build, human-judgment-intensive phases. API-layer AI is finding its home in the post-build, automation-shaped phases.

And when I look at our own tooling — spec-driven development and test authoring on one side, the service investigator on the other — that pattern holds.

But I could be retrofitting a clean story onto a messy reality. Is this how it looks from the outside of my team?

The Use-case Quadrant

The thing that’s still bothering me — the drawer problem

Even with this frame, I can’t fully explain why our drawer keeps filling up.

We have the service investigator — built like infrastructure, wired to real systems, owned by someone, genuinely useful. And we have Jira prompt templates that get recreated from scratch every time someone new joins the team. Spec-driven approaches that drift per-engineer because nobody owns the canonical version. Wiki page prompts that live in someone’s personal Copilot chat history.

The discipline we apply to code — versioning, review, ownership, documentation — we haven’t applied to our AI configurations. And I don’t think this is unique to us.

What I suspect is that the drawer problem and the UI/API distinction are connected: the service investigator got built like infrastructure because it clearly lived on the API-layer side — it had an owner, a purpose, a place in the system. The prompt templates drift because nobody has decided whether they’re UI-layer tooling worth owning as a team, or just individual productivity aids that people figure out for themselves.

Maybe naming the split is what enables the discipline. Maybe it isn’t. That’s a genuine question.

For the leaders reading this: have you found a way to treat UI-layer prompt and agent configurations as shared team infrastructure? Or is the drawer a universal condition of this moment in AI tooling?

The question I’m really asking

This whole piece is a long way of asking something I want to put directly.

Do you see this split — UI-layer versus API-layer — in your own organisations? Are you finding that AI tooling for human-in-the-loop work (spec writing, test authoring, ticket creation, documentation) feels different in character from AI tooling for autonomous, trigger-based workflows (investigative agents, pipeline automation, monitoring integrations)?

And if you are — are you managing the two differently? Are the terms I’ve reached for useful, or do you have better words for it? Is the pre-build/post-build mapping too clean, or does it actually hold in your experience?

I’ve been in the learning phase on this for eight months. The service investigator gave me confidence that the API-layer pattern is real and worth investing in. The drawer full of drifting prompt templates tells me the UI-layer side hasn’t been treated with the same engineering seriousness — and I’m not sure whether the frame I’m proposing helps fix that, or whether it’s a separate problem entirely.

What I’m confident about: the difference between human-in-the-loop AI and autonomous AI is real, and it matters operationally. Whether the frame I’ve landed on is the right one — that’s exactly the conversation I’m trying to start.

If you’re seeing something different, I want to hear it

Maybe the split isn’t UI-layer versus API-layer. Maybe it’s synchronous versus asynchronous. Maybe it’s judgment-dependent versus judgment-independent. Maybe it’s something neither of us has named yet because we’re both too close to our own workflows to see it clearly.

I’m writing this because I think the enterprise community is collectively figuring this out in real time — and the insights are more likely to come from the people living it than from any framework imposed from above.

Written from eight months inside this problem — GitHub Copilot, Atlassian MCPs, Kubernetes and Grafana integrations, and more custom agents than I can easily count. Not a declaration. A question. Comments, pushback, and better terminology all welcome.