The AI interface architect

An AI interface architect, as AR Labs uses the term, designs the interfaces between people and AI: how a person speaks to an AI agent (a language model run in a loop with tools, so it can act, not only reply), how the agent's work and thinking are shown back, and how the whole exchange stays within what both a person and a language model can hold. We think this field needs practitioners who combine skills that are usually separate: building agents, designing conversation and voice, drawing live visual structure, and running systems reliably in production. We organise our own learning around developing that combination.

Why we think the role is needed

Our vision is an interface in which people speak and AI answers with visible concepts: mind maps, pictures of how concepts connect and goal trees rather than text alone. No single existing specialism builds that. Agent engineering, voice engineering and frontend development are usually separate jobs, and each covers one piece. The pieces have to be designed together, because a failure in any one of them, a slow voice reply, a crowded context, an unreadable picture, breaks the experience for the person using it.

We expect much general agent tooling to become commodity, and put our effort into what we expect to stay hard: governance, a person's view and control of agent work, and interfaces that fit how people think. The last two are the AI interface architect's territory, and the layer that VOX OS, our design for an operating layer over agent work, is designed around.

The skills that combine

We lay the role out as a set of connected chains, each running from foundations to advanced work.

Chain	What it covers
Agentic engineering	From model APIs and tool calling to multi-agent coordination, supervisor patterns and agent evaluation
Voice and conversation	Audio streaming, speech-to-text and text-to-speech, custom voice pipelines, latency and turn detection, conversation design
Visualisation	Drawing graphs and hierarchies in the browser, with zoom, pan and animation
Real-time state	Streaming updates from an agent to the screen, and the state of a live graph of concepts
Agent operations	Context engineering, memory design, observability, AI reviewing AI, supervision of long-running agents
Retrieval	Grounding a model's answers in documents through search and retrieval
Foundations	Testing, version control, deployment, and the frontend and backend engineering underneath all of it

The chains depend on each other. Agent engineering leads into agent operations and memory; voice and agents both need asynchronous code that never blocks, because a blocked call in a voice pipeline is heard as silence; frontend work leads into visualisation and real-time state. Our product milestones follow the same path: an interactive component with complex state, then a live graph visualisation, then one that updates from a stream, and finally a voice agent whose conversation is turned into concepts drawn on screen as it happens.

flowchart LR
  A["Agentic engineering"] --> O["Agent operations and memory"]
  A --> V["Voice pipelines"]
  F["Frontend and UI"] --> G["Visualisation"]
  G --> R["Real-time state"]
  V --> X["Voice in, concepts out"]
  O --> X
  R --> X

Choices we make about the role

AI engineering, not machine-learning engineering. The role builds systems around models rather than training them, so model training, fine-tuning and training pipelines are outside it.

Custom pipelines over platforms. For voice, we build our own pipelines on open frameworks such as Pipecat rather than relying on hosted voice platforms, for deeper understanding and control over latency and behaviour.

Engineering foundations alongside the AI specialism. We give testing, deployment and frontend engineering their own chains next to the AI ones, because testing is what separates professionals from people following tutorials.

Comprehension before speed. AI tools can produce code faster than a person understands it. We build with comprehension gates: when the builder cannot explain what is being built, the build pauses for learning until they can.

Learn by building the product. Skills are acquired in service of the product, not in the abstract. Each skill is learned because the voice-in, concepts-out interface needs it.

How it shows up in our work

Our projects are the training ground for the role. Salesbot, a live browser voice agent built on Pipecat, exercises the voice and conversation chain. Vox Canvas and VOX Torch draw our task graph as navigable structure for a person supervising agents. VOX Presenter combines the two: a voice agent discusses a document while a second agent writes analysis on screen. Our coding pipeline and context engineering practice exercise agent operations. The domains of Anthropic's Claude Certified Architect exam (agent architecture, tool design, context management and prompt engineering) overlap the agentic half of the role.

The full combination, a voice conversation turned into a live map of concepts, is our goal rather than a built product. How we organise our own learning toward it is part of the Loop, the cycle by which AR Labs works.