Design the right agent.Then build it right.

The build got cheap. The design didn't.I design the AI agents that live inside your products and services, before a line of instructions is written.

Get in touchSee how I design agents

The build got cheap.The design didn't.

Cursor, Claude Code and Copilot Studio will write an agent's markdown in minutes. None of them can tell you what the agent should be, what it must never do, or who signs off when it acts. That's a design job, and most teams don't have anyone doing it.

Frameworks first, purpose later

Teams pick a platform, then look for a job for it. The agent ends up doing two jobs badly.

"Be helpful" is not a brief

Instructions get written by whoever is nearest the keyboard. Vague briefs make vague agents.

Guardrails bolted on at the end

Legal, policy and compliance see the agent the week before go-live. Approval gates become paint, not architecture.

Every agent gets designed. Usually by accident.

Not UX. Not service design.A new seat at the table.

An AI Agents Designer owns what the agent is, not how it's coded. I sit between your service owners, your engineers and your risk owners, and turn a service need into an agent your team can build with confidence.
How this practice compares
AI Agents DesignerUX / product designerAI engineer
OwnsThe agent's role, persona, skills, tools, memory, channels and guardrailsScreens, journeys and interface patternsThe code, models, integrations and infrastructure
Main outputA signed-off agent design pack, ready to buildPrototypes and UI specsA running agent in production
Works withService owners, legal, policy, compliance, engineeringResearchers, product managers, developersProduct, platform and data teams
AnswersWhat should this agent do, and where must it stop?How should people use this screen?How do we make it run, reliably?
WhenBefore the build, and at every changeThroughout deliveryDuring and after the build

I've done all three jobs. That's why I can design the first one well.

Agent anatomy,designed on purpose.

Every agent has the same parts, whatever the platform. I design each one with the people who own the risk, then hand engineering a pack they can build from in Cursor, Claude Code or Copilot Studio.
Understand the serviceOne user, one job, done well.

What I decide

Which job in the service genuinely needs an agent, who it serves, and what "working" looks like.

What you get

An agent opportunity map and a one-page job statement your service owner signs.
Instructions, role and personaThe brief it reads before every turn.

What I decide

The agent's role, voice, tone, refusals and examples of a good answer.

What you get

instructions.md, written in plain language and critiqued like any design artefact.
SkillsPlaybooks that load only when needed.

What I decide

Which procedures deserve a playbook, what triggers each one, and the quality bar.

What you get

A skills catalogue, one procedure per skill, with no overlap or contradiction.
ToolsIf it isn't a tool, it can't do it.

What I decide

The fewest tools that do the job, read versus write, and which actions pause for a human.

What you get

A tool scope matrix with failure responses for every tool.
MemoryWhat it keeps, and what it must forget.

What I decide

What's worth remembering, what's never stored, and how users see and control it.

What you get

A memory register agreed with your data protection lead.
ChannelsSame brain, channel-appropriate manners.

What I decide

Where people meet the agent (in-product, Teams, Slack, email, API, scheduled runs) and how it behaves in each.

What you get

A channel map with tone, length, interruptions and human handoff per channel.
GuardrailsAutomate the work, not the accountability.

What I decide

Irreversible actions, approval gates, escalation, recovery and cost limits, agreed with legal, policy, compliance and the service owner.

What you get

A guardrail and approval-gate register, signed by the people who own the risk.
Evals and handoffUsability testing, for an actor.

What I decide

Test cases with pass criteria, run before every release.

What you get

An eval suite and a build-ready pack your engineers or AI tools can execute.

Design spine

Five questions behind every part above.

Instructions, tools, guardrails and the rest are different pieces of the same agent. I run these five questions through each one so the anatomy stays coherent and buildable.

  1. Who is it for, and what one job does it do?

  2. What must it never do?

  3. What does it need to touch?

  4. When must a human step in?

  5. How will you know it's working?

Read the Designing Agents talk → (opens in a new tab)

The best agents don't sit beside a service.They live inside it.

Case in point · UK central government

An agent that knows every facility

  • Designed and built an in-product agent for a government finance platform that answers questions about a facility from its own records: amounts, fees, obligations, reinsurance and risk.
  • It stays with the user as they move through the service, rather than living in a separate chat window.
  • Designed the AI-assisted amendment flow: a plain-language instruction becomes a draft set of changes the user reviews and submits, while ordinary questions are answered in the chat, not treated as changes.

InstructionsToolsApproval gatesIn-product channel

What I designed

Role
An SME that answers from the record, not from guesswork.
Tools
Read the facility record; draft changes.
Guardrail
The agent drafts; the user reviews and submits.
Channel
In-product, alongside the journey.

Client and product names shared in conversation, within each client's rules.

I don't just design agents.I build with them every day.

Using AI tools is table stakes. I've been AI-first in my own work for nearly three years, and I've usually been the first person on a project team to make the case for AI-first ways of working, and then show the speed it brings.

973+

days building in Cursor

(opens in a new tab)

2.7B

tokens in the last 30 days

(opens in a new tab)

164

day unbroken build streak

(opens in a new tab)

169

agents run (local and cloud)

(opens in a new tab)

Live, public and verifiable. Check the profile. (opens in a new tab) Figures as of 2026-11-03.

Designed, built and shipped. Live agents, not prototypes.

Among the first in the UK to design and ship AI agents built specifically for user-centred design.

Trusted bydemanding organisations.

22 years.Every layer of the stack.

I started as an engineer in 2004, moved into UX and product design in 2012, and have spent the last eight years on GOV.UK services. Agent design needs all three: the engineering to know what's buildable, the UCD to know what's needed, and the leadership to get it agreed.

  • 22

    years in product engineering and design

  • 16

    years in the UK

  • 8

    years on GOV.UK services

  • 2

    years designing agents into live products

  1. 2004 – 2010

    Engineering

    Nokia, Alcatel Lucent, Wipro, Cognizant, Yahoo!, Orbitz, bwin.party.

  2. 2010 – 2012

    Product UX

    Rank Digital, IBM, Mecca Bingo, Grosvenor Casinos, Blue Square.

  3. 2012 – 2018

    Consulting UX

    British Airways, Just Eat, Betfair, Fiserv, Nationwide, Travelex, Avis Budget, Vodafone, Virgin Media, O2 Business, Fjord / Accenture Interactive, giffgaff.

  4. 2018 – now

    GOV.UK and agents

    The Scottish Government (Social Security Scotland), HMRC, HMCTS, BEIS, Home Office, Cabinet Office, CQC, Ofgem, UK Export Finance, FCDO, Department for Education.

When to bring me in.

  1. Before you build

    You know an agent could help, but not yet what it should do, what it must never do, or who signs it off.

  2. While you build

    The build has started. The instructions, tools and guardrails need designing properly before anything reaches users.

  3. After you've shipped

    The agent is live and not behaving as hoped. It needs redesigning, not just re-prompting.

  4. When you're growing the capability

    You want your own teams to design agents this way, with the methods, templates and confidence to keep going.

Start where you are.

Full-time contract

Embedded in your team as the AI Agents Designer across a programme.

Part-time contract

Two or three days a week alongside your existing UCD and engineering teams.

Consulting

A scoped piece: design one agent end to end, or review an agent before it ships.

Advisory

Ongoing advice to leadership on agent strategy, AI-first ways of working and team capability.

SC cleared · Certified Usability Analyst (HFI) · Master's in Computer Applications · UK public and private sector · Remote, UK-wide

Is "AI Agents Designer" a real role?

It is now. Coding an agent has become the cheap part; tools like Cursor write the markdown. Deciding the agent's job, boundaries and behaviour is the expensive part, and it's a design discipline.

Do you write code?

I can, and I build every day. But on your project I'm the designer. Engineering, or your AI tools, build from my pack, and I stay close to make sure what ships matches what was agreed.

Which platforms do you design for?

Any. The anatomy is the same in Copilot Studio, Claude, OpenAI, Power Platform or a custom build. I design the agent first, then fit it to your platform.

How do you handle legal, policy and compliance?

I bring them in early, not at the end. Guardrails, approval gates and memory rules are agreed and signed off by the people who own the risk, and recorded in the pack.

Do you work on government services?

Yes. I have eight years on GOV.UK programmes, hold SC clearance and design to the Service Standard, the GOV.UK Design System and WCAG 2.2 AA.

How quickly can you start?

Usually within a week or two of a first conversation.

Available now · Contract, consulting and advisory

Let's designyour first agent.

Vijay Kandhalu

Tell me about the role or the agent. I reply within one working day.

Interested in
Prefer LinkedIn?
LinkedIn

Elsewhere