N3XGEN Agentic

N3XGEN is an enterprise integration platform. Teams use it to move data between business systems, for example new Salesforce accounts into Oracle ERP every hour. When I picked up the project, building one standard flow meant clicking through about 25 screens, mapping fields by hand and then hoping the deploy would go fine. AI had been added, but it lived on its own page as a list of models, an API key field and a "safety score 0.65 unsafe" that never explained itself.

The ask was big: make N3XGEN the platform where AI agents do the heavy work. My reading of it was narrower, and I think more useful. Agents should draft, people should decide, and every AI action should be visible and easy to undo. Everything in this case study comes back to that one sentence.

I led UX for the whole project. I owned the vision, the process and the quality bar, and I designed the agent interaction model myself: how an agent asks for permission, how it acts, how it explains itself and how a person undoes it. Two product designers split Build and Run, a researcher owned the research plan, and a content designer owned naming and error copy.

We worked in six weeks with five gates. At each gate the sponsor, PM, engineering, AI/ML and security leads had to agree on one question before we moved on. That rhythm kept a fast project from turning into a fast mess.

Recruiting real users takes time, so I started with what I could check on day one: the product itself. I audited all 21 pages of the existing Figma file against Nielsen’s ten heuristics, with WCAG 2.2 spot checks. It gave us twelve findings, five of them high severity.

The worst one was easy to show. To build one Oracle → Salesforce flow, a person went through about 25 screens. Fifteen of those were the same five-step wizard (Functions, Versions, Mappings, Settings, Review), repeated for the source, the processor and the target.

What the market was doing

Desk research in October 2026 told a clear story. Gartner expects 40% of enterprise apps to have task-specific agents by the end of 2026, and also warns that more than 40% of agentic AI projects could be cancelled by 2027. Open standards like MCP and A2A were making agent crews possible. The EU AI Act and India’s DPDP rules were making audit trails non-negotiable.

I reviewed seven platforms using public information only. Everyone was adding agents. Very few were explaining them.

I wrote six proto-personas from the audit and the stakeholder talks: Arjun the integration engineer, Kavya the architect, Rohit on call, Fatima in data governance, Vikram the platform admin and Neha, a business analyst who knows exactly what she needs but cannot build it. They are hypotheses to test, and the file says so on every card.

Following one flow from request to 2 AM

The journey map follows Arjun building Oracle → Salesforce. It made three moments obvious. Mapping is the lowest point ("Is CUST_NO the same as AccountNumber?"). Deploy is about fear, not effort ("Please don’t break anything on a Friday"). And when something fails, the business team usually notices before the platform does.

The big idea is a crew instead of one all-knowing assistant. Each agent has a narrow job, clear inputs and outputs, the tools it is allowed to use, and a point where it must stop and ask a person. Narrow jobs are easier to trust, easier to test and much easier to explain to a security team.

Autonomy is earned, and it can be lost

Every agent works at one of three levels in each environment: Suggest, Ask before acting, or Act within limits. "Within limits" has a strict meaning: a known fix, a small blast radius, inside budget, rollback ready, inside the allowed time window, and Guardian checks passed. An agent moves up a level only after a person signs it off. Never automatically.

Some things always need a human, whatever the level: any logic change or promotion to Production, new Prod secrets, deletes, sending personal data to a cloud model, going over budget, or raising an agent’s own autonomy.

The old sidebar was icons only, and ten modules had no home at all. I rebuilt the navigation around jobs people do, in nine groups: Home, Build, Run & Release, Operate, Agents, Govern, Connect, Modernise and Admin. Labels are always visible, Ctrl+K works from anywhere, and breadcrumbs follow the object model: Workspace → Project → Integration flow → Run.

We sketched three directions and scored each from 1 to 5 on speed, control, learnability, enterprise trust and build effort. The scores were close, which was the real finding. Each concept was good at one thing.

The client wanted to keep the N3XGEN name and evolve its blue and green. I pushed the action colour to a stronger electric blue, added a deep navy as the ground, and gave AI exactly one colour: violet. Violet means an agent is speaking. Dashed violet means suggested, not applied. That rule is simple enough that people learn it without a tooltip.

The mood board had a "less of" list too: sparkle icons on everything, purple gradients and glowing robots.

Forty screens in eleven groups, desktop first at 1440. Every P0 screen is designed in eight states: default, empty, loading, error with a next step, agent working, needs approval, no permission and read-only in Prod. Here are the ones that carry the story.

The handoff package had tokens, component specs, every agent state, edge cases, Given/When/Then acceptance criteria and a prototype linked from Jira. Frames were marked "Ready for dev" only after the last gate, and design questions got an answer within one working day.

Next, I want to see the research plan run. My bet is on H2, that confidence plus a reason makes people accept agent mappings. If that one is wrong, a lot of this design has to change, and I would rather find out in week one of the pilot than in month six.