01
Errors people can correct
People can spot a bad answer, correct it and carry on with their task.
Recovery after a wrong answer
Measured by Moderated sessions on the prompt set
Capability 01 / 04 · Assistants and agents
We design AI assistants, agents and voice interfaces for products your customers and staff use, and prototype them on a live model. Every screen has a designed state for slow, unsure and wrong answers.
Illustration: an assistant conversation. A user asks which enterprise contracts renew before March and whether pricing terms changed. The assistant shows a read-only plan of three tool calls and answers with three numbered citations. It notes that two scanned contracts could not be read, then proposes drafting reminders to three account owners and waits for the user to approve.
What we offer
Each one decides what the AI does on its own, what it asks for and what it shows so people can judge whether to trust it.
The opening message, questions, refusals and recovery, written as a script and tested with users before any model is connected.
Scripted · tested
How an agent’s plan is shown, paused, edited and approved, with a stop at every step and undo afterwards.
Plan · approve · undo
Voice, camera, document and screen input designed as one, with a switch to typing in noise or poor light.
Voice · vision · document
Citations, confidence, edit history and a plain record of what the AI used, so people check before they rely on it.
Cited · checkable
Streaming text, partial results and clear messages for the four-second wait and the wrong answer.
Streaming · fallbacks
Task-based testing with users on a fixed set of prompts and edge cases, scored for completion, correction effort and trust.
Task success · trust
How we work with you
A working prototype on a live model comes early, because a static mock-up cannot show how AI answers behave. Timings are typical, set per engagement.
We agree the users, their tasks, the data the AI may see and the actions it may take. Risks are listed before features.
Flows, conversation scripts and screens, built in the design system and prototyped on a live model.
Users work through tasks on the prompt set, including cases where the model is wrong; we change the design based on what they do.
Specifications, design tokens and components go to engineering with the prompt set and acceptance criteria attached.
How it works
For each failure we record what triggers it, what the person sees, how they recover and the test that checks it on the live model.
| State | Trigger | What the person sees | Recovery | Tested |
|---|---|---|---|---|
| No source found | Search score too low | Says so, offers search | One tap to a person | 41 / 41 |
| Low confidence | Quality score < 0.7 | Answer with caveat + sources | Ask a follow-up | 38 / 40 |
| Action needs approval | Refund over limit | Plan shown, approve or edit | Named approver | 25 / 25 |
| Prompt injection attempt | Instruction in a document | Ignores it, flags the file | Logged for review | 18 / 20 |
| Out of scope | Legal or medical ask | Declines, explains why | Hand-off with context | 9 / 12 |
Illustrative Taken from a prototype. Yours is written for your own prompt set and policies.
What changes
We take a baseline before design starts and measure again on the live-model prototype. Figures shown are typical; your targets are set per engagement.
01
People can spot a bad answer, correct it and carry on with their task.
Recovery after a wrong answer
Measured by Moderated sessions on the prompt set
02
Plans are visible, consequential actions need approval and anything the AI did can be undone.
Agent actions approved first time
Measured by Approval events in the prototype log
03
Design decisions are tested with users on a live model, so the build starts from what worked.
Task success on the prompt set
Measured by Tasks completed ÷ tasks attempted
What you get
Conversation scripts, the failure-state catalogue, the prompt set and the tested prototype sit in your repositories and design files from week one.

Manifest · AI Apps7 items
| # | Deliverable | Format |
|---|---|---|
| 01 | AI experience brief & capability map | Doc · board |
| 02 | Interaction design & flows | Figma |
| 03 | Conversation & prompt scripts | Doc · prompt set |
| 04 | Working prototype on a live model | Prototype · repo |
| 05 | AI interface pattern library | Figma · Storybook |
| 06 | Experience evaluation report | Report · recordings |
| 07 | Design specification & acceptance criteria | Doc · tickets |
Where it sits
AI Application Design covers what people see and use. Its acceptance criteria become the tests engineering builds against.
Which use case, and why this one first.
The conversation, controls and failure states, tested on a live model.
Agents, document search and infrastructure, built to the specification.
The same prompt set, re-run on every release.
The prompt set written in week one is used at all four stages.
Technologies we work with
Design, model and prototyping tools, most used first. We choose models by testing them on your prompt set.
Also in use
Frameworks we build to
These frameworks shape the automatic checks, failure states and records we hand over. We build to them; we do not hold certifications for them.
Perceivable, operable, understandable and robust content, including 2.2 criteria such as focus not obscured, target size and accessible authentication.
A risk-based regime: prohibited practices, obligations for high-risk systems, transparency duties and rules for general-purpose AI models.
Four functions for trustworthy AI: Govern, Map, Measure and Manage, with a companion profile for generative AI (NIST AI 600-1).
Risks specific to applications built on AI models, including prompt injection (LLM01), sensitive information disclosure (LLM02), excessive agency (LLM06) and vector and embedding weaknesses (LLM08).
Lawful basis, data-subject rights, data protection by design and by default, breach notification and DPIAs for high-risk processing.
Notice and consent, duties of data fiduciaries, rights of data principals, breach intimation and added duties for significant data fiduciaries, with the DPDP Rules.
Services & packages
Buy the design of one assistant, agent or voice interface, or the whole experience from concept to a specification your engineers can build. Designs are prototyped on a live model and tested with users.
How to buy
How we work with you
Ask a quick question, send a project brief or issue a formal RFQ. The lead for the work reads each one in full, and any services already in your brief go with it.
Or book a thirty-minute call01
For a first conversation, a press request or anything that does not need a scope yet.
You get A reply from a named lead
02Recommended
Goals, audiences, a budget band and timing, so our first reply can outline the work.
You get Options and a first scope after one call
03
Your documents, deadlines and the procurement and security rules the work must meet.
You get Receipt confirmed and a named bid lead
How it is priced
Each package shows its pricing model. Work starts once a written scope and quote are agreed.
Opens a project brief with this package chosen.
In your brief
In your brief
In your brief
In your brief
| Package | Every engagement includes | Best for |
|---|---|---|
| SprintA short, fixed-scope engagement that answers one defined question. |
|
Discovery, a diagnostic, a prototype or a decision you need to make soon |
| ProjectA defined scope, delivered for a fixed price. |
|
Work you can describe up front: an identity, a platform or a set of tools |
| MilestoneA larger build in phases you approve and pay for one at a time. |
|
Programmes too large for one contract, where you want control at each step |
| RetainerReserved monthly capacity to run, improve and extend what we built. |
|
Live brands and products that need a steady team without hiring one |
Questions
What buyers ask before AI Application Design work starts.
Book a callWe design the experience; Technology & Intelligence builds the software behind it. That covers the agents, document search, infrastructure and production testing. We design the conversation, the controls and what the screen shows so people can judge an answer. On larger programmes the two run together.
Several; the interface does not depend on one model. We prototype on the models that suit the task, including Gemini, OpenAI, Anthropic, Mistral and open-weight models. You can change model later without a redesign.
We treat a wrong answer as a normal state of the product. Sources and confidence are shown, a correction is one action away, consequential steps need approval and there is always a route to a person. Failure states are designed in the same sprint as the main journey.
Yes. You get a specification, components and a prompt set for your engineers to build against. What we make for you is yours once it is paid for. Tools we already had stay ours, and you get a free, permanent licence to use them. If you need more engineers, ours can join the build through Technology & Intelligence.
Yes; we design to WCAG 2.2 AA. Streaming text is announced to screen readers and every agent action works from the keyboard. No meaning relies on motion alone, and every voice step has a typed equivalent.
Also in AI Design
Each shares the models, evaluation sets and approval rules built here.
All of AI Design
04 / 04 · Measured AI adoption
AI use policy, pilots, roadmaps and training for brand and marketing teams.

03 / 04 · AI Design
Image and copy models tuned to your brand, scored on a brand-fidelity test set.

02 / 04 · Generative media
AI-made films, images and edits, with creative direction and a rights log.
You will speak to a lead who would run the work, and get a straight answer on fit.
Three ways to start
Every engagement starts with a written scope and a quote agreed before work begins.
Choose one of the three ways above