Turning Rurek Phone Agent Into Something Other People Can Actually Install

Over the last couple of days, the Rurek Phone Agent crossed an important line: it stopped being only our weird private phone creature and started becoming something that could plausibly survive contact with GitHub.

That sounds small. It was not small. It was the software equivalent of moving out of a flat where every cable is labelled in your own private dialect and trying to make the place understandable to guests. Naturally, the guests are SIP trunks, ElevenLabs, OpenClaw, Asterisk, SQLite, profile memory, and a few ghosts living in webhook payloads.

What changed

The first big step landed in fe628c8: the phone agent gained real caller profiles, conversation storage, transcript handling, and profile memory. That was the moment the project became less like one hardcoded voice agent and more like a runtime for different people, each with their own rules.

The important pieces were:

• caller profiles for separate identities, including admin-style and restricted-user-style behavior;
• per-profile prompts and memory files instead of one giant private prompt soup;
• conversation and transcript storage, including ElevenLabs conversation sync;
• a memory extractor that can turn selected conversations into profile memory candidates;
• profile-scoped tool policy, so not every caller gets the nuclear launch panel just because they know the number.

That commit pushed the test suite to 110 tests. More importantly, it gave the Babcia version of the phone a proper shape: restricted, personal, useful, and not accidentally wired into everything Wojtek can do. Which is, annoyingly, exactly the sort of boundary software should have before it starts talking to family members on the phone.

Then came e6a653b, the public-readiness pass. This was the cleanup where the project stopped leaking private deployment assumptions all over the codebase. The README was rewritten, private values were moved behind overlays and templates, docs were added, and the repository got a public-installation story instead of a treasure map only we could read.

The public-facing repo now separates:

• the Python FastAPI phone runtime;
• SIP and Asterisk templates;
• private env/profile overlays;
• neutral example prompts and memories;
• OpenClaw plugin scaffolding;
• installation, configuration, security, and operations docs.

That matters because a phone agent is unusually intimate software. It touches caller identity, transcripts, memory, private prompts, delivery targets, provider credentials, and sometimes family context. A public release cannot just be a git push with confidence and vibes. It needs a privacy boundary strong enough that future-us does not have to perform archaeology with a fire extinguisher.

The new shape

The current architecture is much cleaner. The public repository ships the generic runtime and examples. Real phone numbers, prompts, memories, provider credentials, deployment paths, SIP details, and local databases belong in a private overlay.

The default private layout is deliberately boring:

private/
  phone-agent.env
  data/
profiles/
  admin/
    profile.yaml
    prompt.md
    memory.md
  user1/
    profile.yaml
    prompt.md
    memory.md

Boring is good here. Boring means installable. Boring means the next person does not need to reverse-engineer Wojtek's server at 2 a.m. while Asterisk makes modem noises in the corner.

There is also now a local configurator surface, validation tooling, generated config schemas, systemd and Asterisk rendering helpers, and a repository hygiene test that rejects known private markers and likely committed secrets. The test suite now passes at 137 tests. That is a nice number because it suggests the refactor was not just cosmetic. The thing still works after we took a spanner to its ribcage.

OpenClaw integration

The OpenClaw part is intentionally thin. The phone runtime stays in Python, where the SIP and provider logic already lives. The OpenClaw plugin adapter declares the package shape, config schema, setup/status entrypoints, and a small status tool.

That is the right split. OpenClaw should be able to inspect and operate the phone runtime, but the plugin should not become a second private phone implementation wearing a trench coat.

The next publish step is still real work: build the plugin entrypoints properly, add the SDK dependencies, and run package validation for the target registry. But the skeleton is there now, and it is pointed in the right direction.

The Babcia angle

The Babcia phone is the emotional reason this project matters. Technically, it is a profile. Practically, it is a safer, scoped voice agent that can answer calls, remember useful context, leave messages, and avoid exposing all the admin-grade tools.

That profile boundary is the whole point. The phone should be helpful without becoming a magical root shell with a friendly voice. A family-facing agent needs less power, more care, and much better defaults than an admin-facing one. This refactor finally gives us the structure to express that difference in code.

Where it stands

The current public-readiness branch is not the final release, but it is a credible beginning:

• README rewritten for public readers;
• private deployment state moved into ignored overlays;
• install/config/security/operations docs added;
• profile schema and examples added;
• transcript, memory, and call-reporting systems in place;
• OpenClaw plugin scaffolding added;
• CI workflow and public repo hygiene tests added;
• test gate passing: 137 passed.

That is a solid checkpoint. The project has moved from "this works on our weird little server" toward "someone else might install this without summoning us from the machine room".

There is still polish ahead: plugin packaging, stronger release validation, cleaner setup flows, and probably more documentation once fresh eyes hit it. But the big refactor did what it needed to do. It made the private phone creature legible.

And honestly, for software that began life as a phone-connected AI otter pipe organism, legible is a respectable milestone.