What 150 users taught me about agentic UX.

I shipped Argus in 2025. I closed it down in May 2026.

It wasn't a failure. Argus did exactly what it was supposed to do — it got deployed across a hundred and fifty users at 180 Degrees Consulting Southampton, won the £3K Future Worlds Enterprise Prize, got me into rooms with Future Worlds, and pulled fifteen contributors across four university societies into a real engineering team. It taught me how to build, ship, recruit, and sell. Then I let it go.

I'm letting it go because the future is Substrate, and you can't run two ventures at full intensity. But before I move on, I want to write down what shipping Argus taught me about building agentic products. These lessons are the foundation of how I'm thinking about Substrate's UX from day one.

Lesson one: the agent isn't the product. The trust is.

When I first built Argus, I was obsessed with the technical core — multi-agent orchestration, the reasoning loop, getting the LLM calls to chain reliably. I assumed users would care about the same things I did.

They didn't.

What users cared about was whether they could trust the output. Whether the agent's confidence matched its actual accuracy. Whether they could see what it was doing and why. Whether they could correct it without starting over. Whether it remembered what it had done last week.

The technical sophistication of the underlying system mattered exactly zero to the people using it. What mattered was the relationship between the user and the agent's outputs. That relationship is built and broken in tiny moments — a misformatted response, a confidently wrong answer, a slow load with no feedback.

I wasted months optimising the wrong layer. The lesson: build the trust surface first, then make the underlying reasoning good enough to support it. Not the other way around.

Lesson two: agentic UX is a new design discipline

Designing for agentic systems isn't designing for software in the traditional sense. In traditional software, the user has a model in their head of what the program will do, and the UI is a way of expressing that intent precisely. The user is in control, the software is deterministic, and the design problem is making the controls discoverable.

Agentic software is different. The user has a fuzzy goal, the system has latitude in how to achieve it, and the design problem is managing the gap between the user's mental model and the agent's actual behaviour.

This means new primitives:

• Intent confirmation before expensive operations
• Live progress streams so users see thinking, not just results
• Reversibility as a first-class feature, not an afterthought
• Confidence signals baked into outputs, not hidden behind APIs
• Memory affordances — letting users see, edit, and prune what the agent remembers

None of this is in the standard UX playbook. I had to figure it out by watching Argus users get confused, frustrated, and occasionally delighted, and reverse-engineering why.

For Substrate, this isn't a one-person product anymore — it's going to be a tool engineers spend hours a day inside. The UX bar is higher and the failure modes are more expensive (a hallucinated circuit modification can cost a defence customer six figures). The lessons from Argus are the starting point, not the ending one.

Lesson three: the cost of LLM tokens shapes everything you can build

This sounds obvious until you ship something real. With Argus, I had to engineer the entire system to run on a Student Union budget — meaning every prompt, every retrieval call, every agent step had to be economically justifiable.

That constraint forced clarity. I learned to:

• Cache aggressively at every layer
• Route tasks to the cheapest model that can plausibly handle them
• Compress context ruthlessly with structured summaries
• Use small embedding models for retrieval, big models only for reasoning
• Batch operations whenever the latency budget allows

The multi-provider LLM router I'm building into Substrate's core is a direct descendant of this thinking. Routing per task and per cost was a lesson Argus beat into me. At a startup scale where you're shipping to one user at a time, you can be sloppy. At a hundred and fifty concurrent users, every wasted token is a dollar that could have been a feature.

Lesson four: you can't recruit people into a project. You recruit them into a story.

When I started building Argus, I tried recruiting contributors by explaining the technical scope. "We're building a multi-agent system that automates consulting workflows." This worked on basically nobody.

What worked was telling people the story. "Here's a 150-person consulting org wasting hundreds of hours a year on busywork that an AI could do. We're going to build the thing that fixes it. The team will outlast me. You'll have something real to point to." When you frame it that way, talented people from societies that have nothing to do with engineering — Business, Marketing — show up and ask how to help.

The fifteen contributors I pulled across four societies didn't come because they were excited about agent orchestration. They came because the story was something they wanted to be part of. The technical problem was just the vehicle.

For Substrate, the story is bigger and the stakes are higher. "AI finished software. Deep-tech is what's next. The companies building the future of defence, energy, and manufacturing have no AI tools, and we're going to build the platform they end up running on." That's a story I can recruit a senior EE engineer into. "Multi-provider LLM router with agentic orchestration" is not.

Lesson five: knowing when to leave is the same skill as knowing when to commit

Argus could have continued. There were paths to making it bigger — selling it as a SaaS product, expanding to other 180DC chapters, raising on it as a venture. I chose to wind it down.

The reason is simple: the ceiling on Argus was lower than the ceiling on Substrate, and you only get one career to bet. Argus was the proof that I could ship. Substrate is the bet that requires the proof. Continuing both at full intensity would have meant doing both at half intensity, which is the most reliable way to fail at both.

The instinct that pulled me to keep Argus running was the same instinct that made me start it: I don't abandon things I've built. But the founders I respect most have all done this — finished one chapter cleanly, moved to the next, didn't apologise. Sam Altman left Loopt to run YC. Patrick Collison shut down Auctomatic to start Stripe. The pattern is consistent: smart people give themselves permission to stop.

So Argus closes here. The team continues with the codebase as a stable internal tool. I move my full intensity to Substrate. The fifteen contributors who shipped with me have a real product to point to on their CVs. The £3K paid for the development. The lessons go forward.

What I'm taking into Substrate

Six things, ranked by how much they'll shape the early product:

1. Trust surface first, capabilities second. Every agent in Substrate ships with confidence signals, reversibility, and visible reasoning before it ships with new capabilities.
2. Multi-provider routing as a first-principle design decision. Built into the core, not bolted on. Cost per task is a feature, not an optimisation.
3. Memory affordances visible to the user. Engineers don't trust black boxes. They will trust a system whose memory they can inspect, edit, and audit.
4. Story-shaped recruiting. Every hire pitch is an articulation of why this matters, not a job description.
5. Tight wedge, slow expansion. Tracer for the first year. Don't get distracted by the platform vision before the first product is selling.
6. The willingness to close chapters. If something inside Substrate isn't working in twelve months, kill it cleanly. Don't let sunk cost run the show.

Argus was the right thing to build. Closing it is the right thing to do. The lessons travel with me.

Substrate is what's next.

— Yassin