DEV Community: Kiran Krishna P

From UX to AX: Why I Think We’re Not Just Redesigning Interfaces, We’re Redesigning Trust

Kiran Krishna P — Mon, 03 Aug 2026 07:55:25 +0000

A personal take on the shift from user experience to agentic experience — and what it means for the way we design going forward.

The Interface Used to Be the Whole Job
For most of my career (and most of design history, honestly), the job was clear: understand the user, map their journey, build the screens that guide them through it, test, iterate, ship. The interface was the product. If it was intuitive, if it reduced friction, if it made people feel in control,that was success.

That assumption is starting to crack.

Over the last year, I’ve watched AI move from being a feature bolted onto a product to being the thing the product is. Assistants that draft your emails before you ask. Agents that reshuffle your calendar. Tools that recommend, decide, and act — sometimes without waiting for a click. And the more I’ve sat with that shift, the more I’ve come to believe: we’re not designing screens anymore. We’re designing behavior. We’re designing relationships with something that has a mind of its own, even if that mind is statistical rather than conscious.

That’s the shift people are starting to call AX — Agentic Experience (sometimes “AI Experience”). And I don’t think it’s a buzzword. I think it’s the next real discipline shift design has gone through since mobile-first.

What Actually Changes When the User Isn’t the Only One Deciding
The clearest way I’ve found to explain this to other designers is a simple comparison:

Traditional UXAX (Agentic Experience)What you’re designingScreens, flows, static statesBehaviors, decisions, adaptive responsesWho actsThe user, mostlyThe system, sometimes without being askedPredictabilityDefined states, deterministic pathsProbabilistic outcomes, variable by designWhat earns trustUsability, satisfactionExplainability, control, transparency

In UX, uncertainty was the enemy. You designed it away. In AX, uncertainty is the starting condition. The system might behave differently for the same input twice. It might be right in a way you didn’t anticipate, or wrong in a way that feels arbitrary to the user. Your job isn’t to eliminate that unpredictability, it’s to make the experience of it feel safe, legible, and reversible.

That’s a fundamentally different design problem. And it means our old toolkit — wireframes, static journey maps, fixed information architecture isn’t obsolete, but it’s no longer sufficient on its own.

The Five Things I Think Actually Matter (Borrowed, Tested, and Reframed)
I’ve been reading a lot in this space, and the framing that’s stuck with me most — from Forbes Tech Council’s coverage of agentic UX — comes down to five pillars. I want to walk through them not as theory, but as the actual questions I now ask myself when I’m designing anything with an agent in it.

Intent Alignment Does the system actually know what the person wants — or is it guessing and hoping?

This is the one I think designers underestimate the most. It’s tempting to let an agent just act — auto-send the email, auto-book the flight — because that feels efficient. But efficiency without confirmed intent isn’t a feature, it’s a liability. The better pattern I keep coming back to: show your reasoning before you act, not after. “Based on your last three replies, I drafted this — want to adjust the tone?” costs one extra second and buys enormous trust.

Controllability Can the person dial the automation up or down depending on how much they trust the moment?

Full autonomy isn’t the goal. Adjustable autonomy is. I think about this like cruise control versus self-driving — most people want the option to take the wheel back instantly, even if they rarely use it. Designing for AX means designing the off switch as carefully as you design the on behavior.

Explainability When the system does something, can the person understand why — in human terms, not model terms?

Download the Medium app
This is where I think a lot of AI products still fail. A confidence score alone isn’t an explanation. “87% confident” means nothing to someone deciding whether to trust a medical scan result or a financial recommendation. Explainability has to be translated, not just displayed.

Emotional Intelligence Is the system reading the room, not just the request?

An agent that responds to a panicked 2am message the same way it responds to a casual Tuesday-afternoon one isn’t intelligent, it’s just automated. This pillar is the one that convinced me AX isn’t a purely technical problem — it’s a deeply human one. Tone, timing, and restraint have to be designed in, not left to the model to figure out on its own.

Co-Evolution Does the relationship between the user and the system actually deepen over time — like it would with a person?

I like this one because it reframes onboarding entirely. We used to think of onboarding as a thing that happens once, in the first five minutes. In AX, onboarding is ongoing — trust is earned in increments, and the system’s autonomy should expand only as fast as the user’s confidence does.

Where I Diverge a Bit: Frameworks Aren’t the Point, Discipline Is
I’ve also spent time with independent frameworks in this space — like the AX Framework built by UX strategist Marta Fernandez, which reframes AI design as a cycle (Discover, Define, Prototype, Validate, Launch, Monitor) built on heuristics like Override & Fallback, Explain-and-Feedback, and Ethics & Privacy by default. What I find genuinely useful about frameworks like this isn’t the specific labels — different practitioners will name the same ideas differently — it’s the underlying discipline they all converge on:

Design must extend past launch, because the model keeps changing after you ship.
Users need a visible, immediate way to say “stop” or “undo” — not buried three menus deep.
Cross-functional collaboration (design, ML, ops, compliance) isn’t a nice-to-have anymore, it’s structural. You cannot design AX in a UX silo.
Honestly, I think we’re in a moment a lot like early responsive design — a dozen people are independently arriving at very similar principles because the underlying problem is the same, even if the vocabulary hasn’t converged yet. That’s usually a sign a discipline is real, not hype.

My Actual Perspective on All This
Here’s where I’ll be direct: I think a lot of the current AX conversation is still too focused on capability — what agents can now do — and not enough on restraint — what they should hold back from doing without asking.

The products that are going to earn long-term trust in this next wave aren’t going to be the most autonomous ones. They’re going to be the ones that know exactly when to act and when to pause and ask. That’s a much harder design problem than building a flashy autonomous demo, and I don’t think it gets nearly enough attention right now.

I also think there’s a real risk of loss of agency creeping in disguised as convenience. Every time we design a system that acts for someone instead of with someone, we’re making a bet that we understood their intent correctly. When that bet is wrong — and at scale, it will be, often — the cost isn’t just a bad experience. It’s an erosion of the user’s sense of control over their own tools. That’s not a UX metric. That’s a trust metric, and once it’s gone, it’s brutally hard to win back.

So if I had to boil down my own stance on the UX-to-AX shift into one line, it’s this:

We are no longer just designing what people see. We’re designing what a system is allowed to decide on someone’s behalf — and that makes every one of us, whether we like it or not, an ethicist as much as a designer.

That’s the part of this shift I find most exciting, and most sobering. The tools are evolving fast. The frameworks are still catching up. But the responsibility — to design for trust, not just usability — was always ours. AX just makes it impossible to ignore.

Building an Enterprise RAG Knowledge Assistant: Lessons from Production

Kiran Krishna P — Thu, 23 Jul 2026 17:56:24 +0000

When I joined Strokx Technologies as an AI Engineer, my first real project was one that a lot of teams are tackling right now: how do you let employees ask natural-language questions against a large, messy pile of internal documents — and get answers that are actually correct, not just plausible-sounding?

That's the core challenge of Retrieval-Augmented Generation (RAG), and it's what I spent four months building: an enterprise-grade knowledge assistant that ingests internal documentation and answers questions against it, with specific engineering choices aimed at reducing hallucination — the single biggest reason RAG systems fail to earn user trust in production.

Here's how it was built, what broke along the way, and what I'd do differently next time.

Why naive RAG isn't enough

The basic RAG recipe is well known at this point: embed your documents, store the vectors, retrieve the top-k most similar chunks for a given query, stuff them into a prompt, and let the LLM generate an answer.

It works — right up until it doesn't. In practice, naive RAG breaks in a few predictable ways:

Bad chunking splits a table or a procedure mid-thought, so retrieval returns a fragment that's technically relevant but semantically incomplete.
Over-retrieval dumps too much loosely-related context into the prompt, and the model starts blending facts from different documents.
Silent failure — when nothing in the knowledge base actually answers the question, a naive system will still confidently generate something, because nothing in the pipeline is checking whether the retrieved context actually supports the answer.

That last one was the problem I spent the most time on.

The ingestion pipeline

The first real design decision was chunking strategy. Fixed-length chunking (e.g., every 500 tokens) is simple but ignores document structure — it'll happily cut a numbered procedure in half. Instead, I built a chunking step that respects semantic boundaries: splitting primarily on headings and paragraph structure, with a [~400–600 token] target size and overlap between adjacent chunks so that context isn't lost at the boundary.

Each chunk was embedded using [sentence-transformers / OpenAI embeddings — replace with actual model] and stored in [vector database — e.g. ChromaDB / FAISS / Pinecone] alongside metadata: source document, section heading, and ingestion timestamp. That metadata turned out to matter more than I initially expected — it's what let the system cite where an answer came from, which became one of the most-requested features once early users started testing it.

Reducing hallucination

This was the core engineering problem, not an afterthought bolted on at the end. A few things helped meaningfully:

Grounding checks before generation. Before the LLM generates a final answer, the pipeline checks whether the retrieved chunks actually contain content relevant to the query — not just embedding-similarity-relevant, but substantively relevant. If retrieval confidence falls below a threshold, the system returns an explicit "I don't have enough information on this" response instead of letting the model fill the gap with a fluent-sounding guess.

Constrained prompting. The generation prompt explicitly instructs the model to answer only from the provided context and to say so when the context is insufficient — a small thing, but it measurably reduced confident-but-wrong answers in testing.

Source attribution as a forcing function. Requiring every answer to cite the source chunk it came from turned out to be a good hallucination deterrent in its own right — it's harder for a model to fabricate a fact and simultaneously fabricate a plausible-looking citation for it.

None of these eliminate hallucination completely — nothing does, at least not yet — but together they turned "occasionally confidently wrong" into "usually honest about its own uncertainty," which is the bar that actually matters for a tool people are expected to trust at work.

What I'd do differently

If I were starting this again, I'd invest earlier in retrieval evaluation — building a small labeled set of questions with known-correct source chunks, and measuring retrieval precision/recall before ever touching the generation side. I built this mostly by iterating on end-to-end answer quality, which made it hard to tell whether a bad answer was a retrieval problem or a generation problem. A retrieval-specific eval set would have cut debugging time significantly.

I'd also want to expand the ingestion pipeline to handle non-text sources — a lot of internal knowledge lives in slide decks and spreadsheets, not clean prose, and the current pipeline assumes fairly well-structured text documents.

Where this goes from here

RAG is one of those areas where the gap between a weekend demo and a production-trustworthy system is almost entirely in the details covered above — chunking discipline, retrieval evaluation, and treating "I don't know" as a valid and important output. That's the part I found most interesting about this project, and it's the direction I want to keep building in.

The code for this project is on GitHub: Enterprise-GenAI-Knowledge-Assistant

If you're working on something similar or have thoughts on RAG evaluation strategies, I'd like to hear them — find me on LinkedIn or check out more of my work at kirankrishna2024.github.io.