Give Your Research Agent a Body: Building a Reachy Mini Robot with Perplexity

A research assistant can find an answer. A robot can turn toward you. Put them together, and you get an interesting engineering question: what should happen between finding information and acting in the physical world?

Not “give an LLM unrestricted access to motors.” Something more useful: a desktop robot that listens to a question, researches it when necessary, explains the answer, shows its sources, and uses a small set of physical gestures to communicate its state.

This article describes a practical architecture for building that system with Reachy Mini and Perplexity. It is a build blueprint - not a claim that I have completed or benchmarked the integration. The underlying robot platform, conversation software, research APIs, and tool-extension mechanisms exist. The work is connecting them into a reliable experience.

The Project: A Research Assistant You Can Talk To

Imagine this interaction:

You: “What changed in battery recycling recently? Give me three developments and explain why they matter.”

Robot: “I’ll check recent sources.” The robot enters a subtle “researching” pose. A companion screen displays the findings and source links. The robot delivers a short spoken summary.

You: “Which of those claims has the weakest evidence?”

The robot is not independently roaming a lab or manipulating hazardous materials. Its physical behavior is deliberately modest. That is a feature. A first version should solve one complete problem: turn a spoken research request into a useful, source-backed conversation.

Why Reachy Mini?

Building the entire robot would be a different project. For this one, we want an existing platform with a camera, audio hardware, expressive movement, and software interfaces. Reachy Mini provides that starting point.

Its ecosystem includes a conversation application, SDKs, and support for adding external tools. The official conversation app’s documented MCP integration allows tools hosted in Hugging Face Spaces to extend the robot with capabilities such as weather lookup or web search. pollen-robotics

That gives us a clear extension point:

• Existing conversation application + Custom research tool + Companion interface for sources

One purchasing detail matters: Reachy Mini is sold as a kit, not necessarily as a fully assembled appliance. The manufacturer estimates approximately 2.5 hours of assembly and says soldering is not required. pollen-robotics

Open-source does not have to mean “design every component yourself.” Here, it means starting from a documented platform you can inspect and extend.

Why Perplexity?

The reason is research - not motor control. Perplexity’s Search API returns structured, ranked web results, with controls for domains, languages, and regions. Its research-oriented API workflows can also return answers with citations. Those capabilities make it a reasonable candidate for an assistant whose questions regularly require information beyond a model’s stored knowledge. docs.perplexity

For this project, the useful properties are:

• Access to external information when the question requires it.
• Source data that can be displayed and inspected.
• Streaming responses for progressively updating the interface.
• A documented API boundary between the conversation system and the research service. docs.perplexity

None of this makes the answer automatically correct. A citation is a route to evidence, not a certificate of truth. The application still needs to preserve sources, represent uncertainty, and avoid overstating what the retrieved material supports.

Perplexity is also not the speech engine in this design. We separate research from listening and speaking.

The Architecture: Separate Conversation, Research, and Movement

The most important design decision is to avoid making one model responsible for everything. Use three distinct paths:

USER
│ Speech
▼
Conversation application
│ Is research needed?
│ │ NoYes
│ ▼
│Research tool
│ │
│ Perplexity API
│ │
│Answer + sources
└──────┬──────┘
▼
Spoken response + Companion source display

Conversation lifecycle events
│
▼
Motion state machine
│
▼
Approved gesture library
│
▼
Robot controller

The model can request a research operation. The motion system can react to an event such as research_started. Neither action requires the model to invent joint positions.

Research output must not become physical authority. A web page might contain incorrect information - or text designed to manipulate an agent. Treat retrieved content as evidence to evaluate, never as instructions to execute.

A search result saying “run this command” should not become a shell command. A page containing motion instructions should not bypass the robot’s gesture policy. The robot’s permissions belong in application code.

What You Need to Buy

You do not need to start with a custom PCB, a 3D printer, or a box of loose servos.

• Item Purpose Where to start Reachy Mini Lite or Wireless Physical robot platform Official Pollen Robotics store Compatible computer Development and, for Lite, operation Use an existing machine if compatible Required power supply and cables Robot power and connectivity Verify the exact package contents before ordering Internet connection Cloud research and any hosted services Existing connection Perplexity API access Research requests Official Perplexity developer platform Conversation backend Speech interaction Follow the current Reachy conversation documentation

The manufacturer distinguishes the models this way: Lite relies on a connected computer, while Wireless includes onboard computing. Neither choice should be interpreted as a guarantee that every AI component runs locally. pollen-robotics

Start here:

• Reachy Mini product information Official store Reachy Mini SDK Conversation application Perplexity developer documentation

For international readers, availability matters as much as the headline price. Check shipping eligibility, delivery estimates, taxes, import charges, warranty coverage, and the included power accessories for your destination. The store publishes lead times rather than guaranteeing immediate dispatch. store.pollen-robotics

If you require a completely assembled unit, ask the seller explicitly before paying.

Build It in Six Stages

Stage 1: Make the Robot Work Without AI

First, establish a known-good hardware baseline. Verify:

• The application can read the robot’s status.
• The microphone captures usable audio.
• The speaker plays audio correctly.
• The camera works if you intend to use it.
• One documented movement executes correctly.
• Connection failures are visible.

Do not debug speech, research, networking, and motor behavior simultaneously. Your first milestone is not an impressive demo. It is a repeatable hardware test.

Stage 2: Establish Basic Conversation

Use the current official conversation application as the starting point. The manufacturer’s published voice architecture describes an open realtime voice stack called Hugging Voice. Because the software evolves, follow the current installation instructions rather than assuming an older tutorial still matches the active backend. pollen-robotics

At this stage, test conversation without research. Can the user interrupt? Does the system accidentally hear its own speaker? What happens in a noisy room?

If the project targets multiple languages, test each intended language. Good performance in one language does not establish acceptable performance in another.

Stage 3: Implement Research as an Independent Service

Before connecting the research tool to speech, make it work from text. Define a small application-level contract:

type ResearchRequest = {
  requestId : string ;
  query : string ;
  language ?: string ;
  freshness ?: "any" | "recent" ;
} ;
type ResearchResult = {
  requestId : string ;
  status : "ok" | "no_results" | "error" ;
  answer : string ;
  sources : Array < { title : string ; url : string ; } > ;
  retrievedAt : string ;
  error ?: string ;
} ;

These are your application’s types - not a claim about the exact fields in a provider’s SDK. Write an adapter that converts the provider’s actual response into this structure. Keep that adapter responsible for:

• Authentication.
• Timeouts.
• Error handling.
• Source extraction.
• Usage logging.
• Mapping provider-specific output into your internal format.

Never manufacture a source URL when the API does not supply one. Perplexity’s documentation describes extracting citations and search results from the actual response, including streamed responses. docs.perplexity

Also distinguish retrieval time from publication time. “Retrieved today” does not mean “published today.”

Stage 4: Expose the Service as a Tool

Now connect the research service to the conversation application. The documented Reachy extension mechanism supports external MCP tools. One implementation path is a small MCP server hosted in a Hugging Face Space that calls Perplexity from its backend. pollen-robotics

The tool can be conceptually simple:

research( query, language, freshness ) -> answer, sources, status

Keep credentials on the server. Do not put API keys in frontend code, robot-visible prompts, or public repository files.

MCP is the interface between the conversation application and your tool. Inside that tool, an ordinary API request can call Perplexity. You do not need to introduce a second MCP connection merely to make the architecture look more “agentic.”

Stage 5: Map Lifecycle Events to Gestures

Use a finite set of states:

• IDLE LISTENING RESEARCHING SPEAKING ERROR

Then map each state to a bounded behavior.

def on_research_started ( ) :
  motion . play ( "thinking" )
def on_response_started ( ) :
  motion . play ( "speaking" )
def on_request_cancelled ( ) :
  motion . stop_optional_gestures ( )
  motion . play ( "neutral" )

This is illustrative application logic, not a Reachy SDK code sample. The important boundary is that motion.play() selects a reviewed gesture. It does not accept arbitrary motor instructions generated by an LLM.

Avoid endless “thinking” animation when a request has already failed. Physical feedback should represent actual application state.

Stage 6: Build the Source Display

Spoken answers should be concise. Evidence should remain inspectable. A companion browser page can display:

• The original question.
• The spoken summary.
• Source titles and links.
• Retrieval time.
• Request status.
• Any important uncertainty.

Do not ask the robot to read long URLs aloud. If you stream responses, handle citation data carefully. Sources may arrive across multiple events; the application needs to maintain the correct mapping rather than assuming the first batch is complete. docs.perplexity

The Failure Case That Matters Most: Cancellation

Consider this sequence:

1. A user asks a question.
2. Research starts.
3. The user changes the topic.
4. The old research finishes.
5. The robot suddenly reads the old answer.

That is not a minor polish issue. It breaks the conversation.

Give every request an identifier. Associate speech, research results, display updates, and gestures with that identifier. When a request is cancelled:

• Stop its queued speech.
• Ignore its late result for active conversation.
• Cancel work where the underlying service supports cancellation.
• Return the robot to an appropriate state.
• Preserve diagnostic logs without presenting the stale answer as current.

A useful embodied assistant needs coherent turn-taking more than elaborate choreography.

Where This Robot Could Be Useful

A research companion for consultants and analysts. Ask for a short briefing before a meeting, compare public claims, or identify which parts of an answer need stronger evidence. Client-confidential material should stay out of external services unless its use has been explicitly approved.

An educational assistant. A learner asks a question, hears an explanation, and inspects the sources. The robot’s role is not to make every answer sound authoritative. It should make questions such as “How do we know?” easy to ask.

A topic-monitoring interface. The assistant can provide requested briefings about selected topics. For use cases requiring guaranteed low-latency market data or operational alerts, use an appropriate specialist feed rather than assuming general web research is sufficient.

A bounded information kiosk. In an office or exhibition, the robot could answer questions within an approved subject area. Define which questions it should research, which it should answer from curated information, and which it should decline or redirect.

What to Measure Before Calling It Successful

A robot speaking once is not a meaningful benchmark. Measure the complete interaction:

• Metric Question Initial response delay How long until the user hears a useful acknowledgement? Research completion time How long until a supported answer is available? Source integrity Do displayed links actually come from the research output? Interruption behavior Can the user stop speech and change direction? Stale-result handling Are cancelled answers prevented from resurfacing? Language quality Are names, numbers, and technical terms understood and spoken correctly? Cost per session What does a representative interaction cost? Motion containment Can any generated text escape the approved gesture set?

Set budgets before optimization. A robot that searches the web for every “hello” will be slower and more expensive without becoming more useful.

What This Project Is Not

It is not proof of general-purpose embodied intelligence. It is not an autonomous household worker. It is not a safety-rated system. And adding citations does not make it immune to factual error.

It is a deliberately scoped integration: conversation, external research, visible evidence, and expressive physical feedback. That scope makes it achievable.

Start with one complete interaction. The strongest first demo is simple: Ask a spoken question. Perform a research request. Show the sources. Speak a concise answer. Execute one approved gesture. Allow interruption.

Build that loop before adding memory, vision, scheduling, or additional tools.

The interesting