PRS / Tobias

PRS stands for Personal Robot System. It is an internal product we have been developing at Bolha to turn humanoid hardware into a social, conversational experience.

I am one of the people building it. My role covers experience and conversation design, the operator interface and parts of the software itself. The system is shared work across the Bolha team; this case focuses on the decisions and implementation areas where I contribute directly.

Social behaviour asks a lot from a machine. The robot needs to hear someone, understand the turn, decide whether another capability is needed, answer at the right moment and coordinate that answer with its body. Camera input can change the conversation. A recalled memory can give it continuity. A gesture can support what it says or make the same sentence feel completely wrong.

Within that runtime, the personality profile shapes how those capabilities are used and how the robot presents itself.

The conversational model sits inside a layer we call Brain and Soul. It manages the live voice session, interruptions, personality context and the coordination between speech and action.

The model does not control the robot hardware directly. PRS gives it a registered set of capabilities for memory, vision, gestures, motion, lighting, audio cues and system context. Requests pass through an orchestrator that checks the capability, routes it to the correct module and reports the result back to the conversation.

That boundary matters in a physical product. If the robot needs to look at the room, for example, the model requests an image from the vision module. The runtime waits for a real camera result before the robot responds. Memory works through the same path. PRS can capture information from a conversation, store it dynamically and bring it back in a later session.

Provider and hardware details can change while the personality remains usable. That is how the same PRS runtime can support different robots and deployments.

At Bolha, I have been involved in PRS while the system itself was taking shape. I define interaction behaviour, prototype flows, design the WebUI, shape personality settings, test the robot, debug realtime failures and contribute to the implementation.

Working this close to the runtime changes the design process. Latency is no longer an engineering detail when a person is waiting for an answer. A camera that is connected but returns an old frame creates an experience problem. The same is true when a memory arrives late or a gesture starts after the sentence it was meant to support.

The architecture is split into modules. In front of the user, every delay, error and action belongs to the same robot. I stay involved in both sides so the design accounts for what the runtime is actually doing.

One PRS interface is made for the people configuring and operating it. The WebUI is where we create personality profiles, manage memories, choose runtime settings, start conversation sessions and see what every module is doing.

Profiles hold the parts that belong to the character, including identity, voice and conversational instructions. Advanced presets control the technical environment: which modules are active, how the hardware behaves and which runtime policies apply. Keeping those layers separate means we can adjust a personality without hiding infrastructure choices inside it.

The live controller exposes camera and audio feeds, robot state, events, logs and direct interventions. I designed and developed these surfaces to make the system understandable while it is running. When something feels wrong in front of the robot, the operator needs to tell whether the problem came from audio, the model, a provider, the network or the hardware.

The public-facing interface has no conventional screen. People meet a body. They speak, interrupt, move in and out of the camera, wait for a response and read meaning into every pause.

I design that interaction across voice and physical behaviour. The work includes how the robot opens a conversation, how it handles an interruption, when a gesture should accompany speech and how information from vision or memory enters the reply. It also includes recovery. The robot has to remain legible when a capability is unavailable or an action takes longer than expected.

On PRS, conversation design ends up in the body. A written response can be correct and still fail when the voice timing feels off, the arms move at the wrong moment or the robot does not acknowledge the person standing in front of it.

Tobias is the main personality we run on Bolha’s Unitree G1 Edu. His voice, point of view, memories and behavioural instructions live in PRS, separate from the robot body itself.

Because those traits live in PRS, Tobias can respond to what the camera sees, recall information from previous interactions and use gestures or movement while he speaks. His personality gives those capabilities a consistent tone, so they feel like parts of the same character instead of separate demonstrations.

We have taken Tobias into situations that are difficult to reproduce in a lab. At Summit Iguassu Valley, he appeared on stage during an event that brought together more than three thousand attendees. At Ciência Aberta 2026, he spoke with visitors, danced, performed capoeira and interacted with Germana Pires during an event that received around 30,000 people.

He has also appeared in podcast settings, where the interaction lasts longer and moves beyond a quick demonstration. Follow-up questions, opinions and interruptions put the personality and conversation design under a different kind of pressure.

Tobias is the best-known expression of PRS. Separating personality from the robot body also lets us build a different character for another context.

At gamescom latam 2026, PRS powered Sol, a gamer personality created for Claro. Sol knew the brand’s products, spoke from a gaming and geek-culture perspective and appeared in a CJ costume from GTA: San Andreas. He talked with the crowd, danced and performed staged fights.

We changed the voice, knowledge, instructions and behaviour for that deployment while keeping the same robot platform. The result was recognisably Sol rather than Tobias. It made the product boundary clear: Tobias is a personality; PRS is the system that makes another one possible.

PRS is still in development. Every public deployment gives us situations that are hard to invent in advance: several people speaking at once, noisy rooms, unexpected requests, unstable networks and actions that take longer on hardware than they did in a prototype.

Those moments keep changing the product and my work on it. I have become more precise about runtime state, interruption and recovery because people notice each one through the robot’s behaviour. A delayed reply can feel like hesitation. A stale memory can change the character. A gesture at the wrong time can undo an otherwise good response.

My definition of interface design is wider now. I still spend time on screens, but some of the most important decisions happen in event queues, personality instructions or the few hundred milliseconds between hearing and replying. PRS keeps moving those decisions closer to the code.