Agent software for care and domestic robots
A robot should earn its place.
Petrixia is being built so a robot can understand an ordinary spoken request, carry out approved tasks, and know when to stop and hand back to a person. Not a technology demonstration — repeatable help that people choose to keep using.
What it is
Three capabilities, and nothing pretending to be a fourth.
Petrixia is the software layer between a person and a machine that can act. It is scoped deliberately narrowly, because a narrow claim can be tested.
Talk naturally
Ask for help in ordinary language. No specialist robot interface to learn, no command syntax to memorise, no app to open first.
Do useful work
Connect that conversation to practical assistance — through a robot body or another approved interface — and verify afterwards that the work actually happened.
Know when to stop
Escalate to a person when a request is unsafe, uncertain, or outside the permitted scope. Stopping well is a feature, not a failure mode.
Built for a changing robot market. Robot hardware is improving faster than any single platform bet can survive. Petrixia is therefore developed as the software product rather than tied to one robot body — research currently spans simulation and multiple physical platforms. That keeps the focus on the part a user actually experiences: whether the robot is helpful, understandable and dependable in an everyday setting.
How it works
The world keeps the truth. The agent keeps its mind.
Most agent demos let the model both act and report on its own success. Petrixia is built the other way round: an authoritative world holds ground truth, and the agent reaches it only through the same narrow gateway a human player uses.
One protocol for both
Every action — a person pressing an arrow key, or the agent deciding to fill a cup — becomes the same structured command. That means behaviour observed in testing is behaviour produced by the real interface, not by a special path built for the demo.
Actions become true by happening
A request does not succeed because the agent believes it did. Turning on a tap starts a timed world process; the cup fills; events report the water level and, eventually, that it is full. Belief and outcome stay separable.
A task, as the world receives it
# the same commands a human player's actions produce cup: take cup: place under tap tap: turn on world: wait until cup is full, timeout 20 seconds tap: turn off cup: take
Evidence
Scored by the world, not by the robot.
A benchmark harness runs whole scenarios end to end and scores them from the world's records. The world is reset before every run — without that, a run inherits wherever the last one left things, and an object dropped conveniently nearby can make an identical task look eight times cheaper than it is.
| Scenario | Body | Score | Effort | Note |
|---|---|---|---|---|
| salon_visit | jamie | 100.0 | 7 | Multi-step booking flow completed. |
| wash_up | beatriz | 90.4 | 14 | Navigation costs it two blocked steps. |
| examine_newspaper | bruce | 0.0 | 0 | Target never perceived — see limits below. |
Honesty constraints
These are what make a score mean anything. The embodiment reaches the world only over public HTTPS, through endpoints limited to what a body could actually perceive. It must never:
- read the world's database;
- read the world's source or map files;
- use the full-world snapshot the browser is given.
Configuration loading refuses a config containing database credentials, or one pointing at localhost — so the honest path is also the easy one.
Known limits, stated plainly
- Navigation only reaches what has been seen. Perception is radius-limited, so a body cannot route to a landmark it has never observed. That is why one scenario scores zero. It is a real robotics problem, correctly surfaced — not a bug papered over.
- No speech channel yet. The agent endpoints carry no chat, so an embodied agent cannot yet hear a person or reply. This is the main blocker for conversational assistance.
- Reasoning is not yet connected. Scripted plans currently stand in for the agent's decisions. Everything below that seam is finished and does not change when the real thing is attached.
Roadmap
Five steps to an embodied agent. Two are built.
The programme is sequenced so that each step is independently testable and the expensive, hardware-dependent work comes last.
-
World adapter and control loop Complete
Sense, plan, step, and correct on contact. An occupancy grid built from observation alone, with A* planning over what the body has actually seen.
-
Skills, telemetry and benchmarks Complete
Navigation and manipulation skills, each result verified against the world; a JSONL record of intent versus outcome; a scenario runner and scoreboard that resets the world between runs.
-
Reasoning connected to the body In progress
Replace scripted plans with the agent's own decisions over the same interface. Nothing below this seam changes — which is the point of building it in this order.
-
Speech and exploration Next
A conversation channel so an embodied agent can hear a request and answer it, plus exploration or prior knowledge so it can reach places it has not yet seen.
-
Physical platform trials Planned
The hardware adapter implements the same interface the simulated world does. Moving to a physical body is a directory copy and a configuration change, then supervised trials against the same benchmark suite.
Safety position
Bounded on purpose.
Petrixia is intended for bounded, non-clinical assistance. It is not presented as a medical device, an emergency service, or a substitute for professional care.
Start where failure is safe
The design principle is to begin with tasks where success is observable, failure can be handled safely, and a person can take over at any point.
Permission lives in the world
An agent never owns a body — it holds a temporary, revocable lease on a body the world owns. Permission checks, collision and world rules sit outside the agent, where it cannot argue with them.
Everything is on the record
Commands are idempotent and audited; every action writes an ordered event. What the agent intended and what actually happened can always be compared after the fact.
Applications
Where an agent like this earns its keep.
Early scope favours ordinary, repeated, low-stakes household and support tasks — the ones people actually want help with, and where a mistake costs a re-run rather than harm.
Domestic assistance
Fetching, tidying, preparing, and the small sequenced chores that make up a day — carried out from a plain spoken request rather than a configured routine.
Care support, non-clinical
Company, reminders, and practical help around the home, with escalation to a person built into the design rather than added afterwards.
Contact
Work with us.
We are interested in conversations with robot platform makers, care and assisted-living operators, research partners, and funding programmes supporting applied robotics and AI.
At a glance
- Stage. Working system, pre-commercial.
- Approach. Hardware-independent agent software.
- Validation. Reproducible benchmarks scored by an authoritative world.
- Scope. Bounded, non-clinical assistance.