Roadmap#

What stands between Pimpo and being a serious alternative to OpenClaw and Hermes Agent, in the order we plan to build it. Written 2026-09-29.

Pimpo already does what they do not: tasks become tested routines that run without a language model, and every action passes rules, approvals, undo and a tamper-evident log outside the model. What it lacks is mostly distribution and ecosystem (nobody can install it yet, and there is little to install into it), and a few open-ended powers that people use those agents for every day: a browser, a shell, long tasks.

The order comes from scoring each item with Jev (TypeSafe) on user value, differentiation, how much its absence blocks adoption, build risk and safety risk (see the scores), then reviewing the result by hand. Where the order differs from the scores, the reason is written down.

Principles#

• Foundation before features. A release nobody can install, or one that breaks on real accounts, makes every feature worthless.
• New powers keep the promises. Anything that gives the agent new reach (a browser, a shell, a phone) goes through an RFC, runs through capabilities, rules and approvals like everything else, and is covered in the threat model before it ships.
• Explore once, then compile. Each new power should also work inside routines, so it becomes cheap and repeatable instead of a model call every time.
• Measured, not assumed. Every milestone ends with criteria checked on real use, not only on the proof suite.

Milestones#

Sizes: S is days, M one to two weeks, L several weeks. Items marked owner need something only the project owner can do (an account, a certificate, a decision).

M1 · Solid ground (v0.6)#

Goal: someone who is not the author installs Pimpo, sets it up in minutes with what they already have, and it keeps working on their real accounts.

1.1 Fix the bugs found while documenting · S#

Found while writing How routines work and Configuration:

• repair never receives the failure message (Explore.Repair is always called with an empty problem);
• routines started only by a webhook log a false "invalid schedule" failure on every reschedule;
• answering a question runs a paused routine, where a webhook refuses with 409;
• approvals wait 30 minutes while a scheduled run is cancelled after 15;
• Run now activates a paused routine;
• pimpo routines import --data DIR fails when DIR does not exist;
• the over-budget message points to Cost, but the limit is set in Settings › General;
• the provider validation message lists 4 providers of 13;
• the judge ignores the configured Ollama address;
• PUT /api/settings empties the fields it does not receive;
• the home-network listener ignores the port in --addr;
• the liberal safety level lets irreversible actions through without asking, unlike what its label says.

Done when each has a test that failed before the fix, and the docs describe the fixed behavior.

1.2 Setup in minutes without Claude Code · M#

Today exploring and compiling assume Claude Code. A new user should get to their first routine with only an API key (any of the 12 providers) or a local Ollama, in under five minutes.

• The welcome screen detects what is there (Claude Code, Codex, opencode, Ollama, LM Studio) and otherwise asks for one API key, tested with one word.
• It picks sensible models per job for that provider and a daily limit, and says what a routine will cost.
• Exploration and compilation are proven on at least two API providers and one local model, with the proof suite's success rate recorded for each.

Done when five people who never used Pimpo reach a working routine without help, on macOS, Windows and Linux, with at least one of them on Ollama only.

1.3 Validate with real accounts · M (weeks of calendar time)#

The proof suite passes 20 of 20 on simulated data. Real mailboxes, calendars and sheets are messier.

• Run the 10 most common routines (morning brief, inbox triage, bills, price watch, news podcast, reminders…) on at least three real households for three weeks.
• Record every failure, silent or loud, and whether repair fixed it.
• Turn each new failure into a scenario in the proof suite.

Done when three weeks pass with no silent failure, every loud failure repaired or explained, and irreversible actions always approved.

1.4 First release · S · owner#

• Push the pending work and get CI green on Linux, macOS and Windows.
• Release v0.6.0 from Actions › release (binaries with checksums, desktop installers for macOS, Windows and Linux, a draft release reviewed by hand).
• Changelog, release notes in English and Portuguese, and the install command working against the release.

Done when curl … | sh, the .dmg, the .exe and the .deb each install and start on a clean machine.

M2 · Easy to get and keep (v0.7)#

Goal: installing, trusting and updating Pimpo is as easy as any mainstream app, on a laptop or a server.

2.1 Auto-update with rollback · M#

• The desktop app checks for updates (Tauri updater, update manifests signed with a key held by two maintainers), shows what changed, and installs on the next restart.
• A snapshot is taken before every update, and go back to before the update is one click, as the release policy promises.
• The server binary updates itself too (pimpo update), with the same checks.
• Beta and stable channels.

Done when an update from v0.7.0 to v0.7.1 happens without a manual download on all three systems, and a broken update rolls back.

2.2 Official signing · S · owner#

• macOS: an Apple Developer ID certificate and notarization. The workflow already signs and notarizes when the APPLE_* secrets exist (owner: the Apple Developer Program membership and the secrets).
• Windows: Authenticode signing of the installers, with a certificate or Azure Trusted Signing (owner: the account).

Done when the installers open without "unidentified developer" or SmartScreen warnings.

2.3 Docker and a server install · M#

Much of OpenClaw's and Hermes's use is on an always-on server.

• An official multi-arch image (amd64, arm64) published to GitHub Container Registry, running as a non-root user with the data folder as a volume.
• A compose.yaml with health checks, and a guide for a VPS and a home server (Raspberry Pi), with remote access over Tailscale (already built in) instead of open ports.
• The desktop and phone apps connect to that server instead of running their own.
• Backups of the volume covered by the existing cloud backup.

Done when a new VPS runs Pimpo in under ten minutes following the guide, and the desktop app is paired with it.

2.4 Packages · S#

Homebrew (formula and cask), winget, Flathub and a Debian/RPM repository, updated by the release workflow.

Done when brew install pimpo, winget install Pimpo and flatpak install pimpo each install the latest release.

2.5 Website and demo · M · owner#

A site (owner: the domain) with what Pimpo does differently, a two-minute video of a request becoming a routine, the documentation, and the downloads per system. A comparison with OpenClaw and Hermes that is factual and dated.

Done when the site is live, linked from the README and the release notes.

M3 · An ecosystem (v0.8)#

Goal: a new user finds useful things to install on day one, and anyone can share what they built.

3.1 Publish the gallery and the protection list · M · owner#

• Create the pimpo-gallery and pimpo-protection repositories (owner), with their signing keys held by two maintainers, and point Pimpo's defaults at them.
• Grow the gallery from 11 to about 50 routines that each solve a real, common need, each signed, audited and with tests, in the 10 languages.
• A contribution path: a pull request template, CI that verifies signatures and audits, and credit for authors in the app.

Done when 50 routines install from the app, and at least five came from people other than the maintainers.

3.2 SKILL.md skills · L#

OpenClaw's ClawHub and the agentskills.io format have thousands of skills. Pimpo can use them without inheriting their risk.

• Install a skill from a folder, a URL or ClawHub. Pimpo reads its SKILL.md, shows what it asks for, and maps it to declared capabilities: a skill can only use what the owner allowed, and scripts inside it run only in the sandbox (4.2).
• Skills are text that reaches the model, so they count as low-trust content: they can never grant themselves capabilities or change rules.
• The protection list flags known-malicious skills.
• A skill that works is offered for compilation into a routine, like any exploration.

Done when the 50 most installed ClawHub skills that make sense for a personal agent install and work, each limited to what it declares, and the known-malicious ones are refused.

3.3 Proactivity · M#

The thing OpenClaw and Hermes users love most is an agent that starts the conversation.

• A daily (configurable) loop where a cheap model looks at what changed (email, calendar, feeds, failed routines) and suggests one or two things: "you pay this bill every month; want a routine for it?".
• Suggestions go to the inbox and the channel, never act by themselves, and learn from being ignored.
• Every suggestion stays inside the daily spending limit.

Done when in real-account use (1.3) at least a third of the suggestions are accepted, and nobody turns it off for being noisy.

M4 · Hands (v0.9)#

Goal: the open-ended tasks people give to OpenClaw and Hermes (a site with no API, a script, a file to transform) work in Pimpo, safely.

These three items give the agent the broadest new powers on this roadmap. Jev rates their safety risk the highest of all (see the appendix). Each starts with an RFC and a threat-model update, and ships behind a Labs flag first.

4.1 Agent-driven browser · L · RFC#

• A browser the agent drives (open, read, click, type, choose, upload, download), isolated in its own profile, with the owner's logins only for the sites the owner allows, stored in the vault.
• Every browser action is a capability with a risk: reading is read; submitting a form, buying or sending is irreversible and asks first, with a screenshot of what will be sent.
• Page content is low-trust: nothing on a page becomes an instruction, and the protection list blocks exfiltration.
• Browser steps that worked are compiled into routines, with selectors and a fallback to re-exploration when a page changes.

Done when ten common tasks on sites without an API (booking, a utility's bill, a government portal, a shop order status) work in chat and as routines, with every submission approved.

4.2 Code sandbox · L · RFC#

• Run shell commands and code (Python, JavaScript, shell) in an isolated sandbox: a container or a lightweight VM locally, over SSH on a host the owner adds, or in the Docker deployment (2.3).
• No secrets and no network by default; the network opens only to domains allowed per task; files come in and out only through declared folders.
• Anything that leaves the sandbox (a file written outside, a request to a new domain) passes the rules and approvals.
• Used by explorations, by skills (3.2) and inside routines, where a script step is recorded and tested like any other.

Done when data tasks (convert a spreadsheet, analyze a CSV, resize photos, run a script from a skill) work end to end, and a red-team pass cannot reach a secret, the host or an unallowed domain from inside the sandbox.

4.3 Learning the owner · M#

• A model of the owner's preferences (tone, what matters, who is important, times) built from corrections, choices and ignored suggestions, kept in memory with provenance, readable and editable in Memory.
• It shapes answers, suggestions (3.3) and the judge's prompts; it never changes rules or capabilities.

Done when in blind comparisons the owner prefers answers with it over answers without it, and every learned preference can be traced to where it came from and removed.

M5 · Everywhere (v1.0)#

Goal: v1.0, with stable formats and Pimpo present wherever its owner is.

5.1 Stable formats for v1.0 · M#

The event log, routine, connector and backup formats are frozen as Releases and support promises: newer versions read older data, and every upgrade snapshots first. An LTS line starts.

5.2 The phone as part of the agent · L#

The phone app becomes a node: camera (a photo of a receipt or a document), location (routines that run when arriving somewhere), the phone's notifications and shortcuts, each a capability the owner grants on the phone, with the same rules and receipts.

Done when a routine can be triggered by arriving home and another by a photo of a bill.

5.3 Voice conversation · M#

A wake word on desktop and phone (on-device), and continuous spoken conversation using the local voices and Whisper already built in, with barge-in. Approvals are never given by voice alone for irreversible actions.

5.4 Parallel agents and long tasks · L#

A large job ("compare these 20 suppliers and prepare a proposal") is split across several agents that run in the background for hours, with a plan, progress in the app, a budget for the whole job, checkpoints that survive a restart, and a final report. Each agent has only the capabilities its part needs.

5.5 More channels · M each#

• iMessage on the Mac.
• Personal WhatsApp. The unofficial protocol can get a number banned and breaks without warning. Offered only with a clear warning, off by default, and never as the only way to approve.

M6 · Each person their own (v1.1)#

Goal: several people share one Pimpo and nobody sees anyone else's things, not even the owner who runs it.

6.1 A login per person · M#

Every device and session belongs to one person and every request acts only for them. The owner pairs a phone for someone (a QR code that signs in as them); removing a person revokes their devices.

6.2 Privacy between people · L#

Every route has an access rule, and a route without one is the owner's. Routines, explorations, runs, conversations, memory, receipts, approvals, questions, recordings, jobs and the phone belong to their person; the owner administers the house (people, connections, models, rules, backups) but sees none of it. Members answer their own approvals; a lasting "always" is a house rule, so it stays the owner's. The live event stream gives others only an event's type.

Done when a test calls every route as a member with the owner's ids and as the owner with the member's, and nothing crosses.

6.3 Passkeys and sessions · M#

A passkey to sign in on a computer, sessions that expire and can be revoked one by one, and a limit on sign-in attempts.

M7 · At a glance (v1.2)#

Goal: any number of dashboards per person, any routine as a widget, and widgets outside the app, each on its own: floating on the Mac, Windows and Linux desktop, and on the home and lock screens of Android and iOS. The design is RFC 0003.

• 7.1 Widgets and snapshots · M. A widget.show capability (Notify) with fixed kinds (metric, list, status, text, table, chart), snapshots and history, built-in widgets, the dashboards API, private to each person.
• 7.2 Dashboards in the app · M. Several per person, a grid to drag and resize, a phone layout, live updates, stale marks and refresh.
• 7.3 Routines become widgets · M. A compiler rule for "show me…", Turn into a widget as a new approved version, and status widgets from any routine's runs.
• 7.4 Floating desktop widgets · M. Each widget its own always-on-top window on macOS, Windows and Linux, hidden while the app is locked.
• 7.5 Android widgets · L. A read-only widget key and feed, and Glance home-screen widgets.
• 7.6 iOS and macOS widgets · L · owner. A WidgetKit extension with lock-screen redaction; needs the Apple Developer account.
• 7.7 Windows Widgets board · M. Only if people ask for it after 7.4.

M8 · Less friction (v1.3)#

Goal: the small things people run into every day stop getting in the way. Most items are small and several come from what OpenClaw 2.0 and Codex shipped in 2026, adapted to Pimpo's rules.

8.1 A reply answers its notice · S#

Telegram and WhatsApp already put a notice's choices on buttons of that message. On Discord, Slack and Signal, which have no buttons, replying to a notice (the channel's own reply) with a number answers that notice, and only that one, however old it is and whatever arrived after it. A bare number keeps working for the latest notice as today. A reply to a notice already answered, expired or meant for someone else says so and does nothing.

Done when a reply to an older notice resolves it while a newer one waits, on every channel that has replies. Done.

8.2 Conversation search · S#

Search earlier conversations by words or an exact phrase, each person only in their own. Done.

8.3 Approvals bound to the operation · M#

"Approve for this routine" lets a routine repeat one action without asking again, as long as the action is the same: the same capability, recipients, hosts and amounts within the approved limit. Anything different asks again, and the owner sees and revokes these approvals in one place. It replaces most uses of a broad "always" rule. Done.

8.4 Questions as cards · M#

A routine's question offers its choices as buttons in the app and on every channel with buttons, and a typed answer is checked against them. Done.

8.5 Settings history · S#

Every change to rules, budgets, connections, models and people is recorded with who made it and when, secrets hidden, and can be undone. Done.

8.6 Database integrity · S#

Pimpo checks its database at start and before every snapshot. A damaged one is set aside, the last good snapshot is offered, and nothing is written over it. Done.

8.7 Private credential prompts · S#

When a routine or a connection needs a password or key, Pimpo asks for it in a form of its own that writes straight to the vault; it never passes through a chat, a channel, a model or the log. Done.

8.8 Lasting progress · S#

Long jobs and routine runs show progress that survives a reload and follows the person to the phone and the channels. Done.

M9 · Where the family already is (v1.4)#

Goal: Pimpo meets people in the apps they already use and learns without being told twice, without giving up any promise of M6.

9.1 A Telegram dashboard · M#

A Telegram Mini App with the person's approvals, routines, spending, questions and their M7 widgets, signed in as that person. Done.

9.2 Push triggers · M#

Gmail (through Google's push notifications), Slack and GitHub start routines as events happen, instead of Pimpo checking every few minutes. The events reach routines as data, like everything read from outside. Done.

9.3 Who owns a memory · S#

Each fact shows where it came from (a conversation, an email, a routine), and a person can delete everything derived from one source. Done.

9.4 Lessons to review · M#

When Pimpo notices something worth keeping (a preference, a routine it could compile, a fix that worked), it proposes it as a lesson; the person accepts, edits or rejects each one in one place. Nothing becomes a rule or a routine without that. Done.

9.5 Models and spending per person · S#

The owner chooses which models each person and each assistant may use, and a daily limit per person inside the house's. Done.

9.6 A live model catalog · S#

The list of models comes from the providers themselves, with prices, and long conversations with Anthropic use its server-side context compaction. Done.

9.7 Outside password managers · M#

Secrets can live in 1Password or HashiCorp Vault; Pimpo keeps only a reference and reads the value when a connector needs it. Done.

9.8 One list of what needs you · S#

Approvals, questions and failed routines in one list, newest and most urgent first, on the app and the phone. Done.

To study before planning#

Each would need an RFC first:

• A house conversation. Several people in one conversation (planning a trip), opt-in, with named participants, and without anyone's private memory reaching it.
• Site tools (WebMCP). Using the tools a site declares instead of clicking through it, under the same host scope and risks as the browser.
• Computer history as memory. Only on the person's own computer, off by default, and probably not at all.

M10 · A company of agents (v1.5)#

Goal: a person creates a company of any kind, hires agents into roles of their own with their own accounts, routines and budget, and sees it work: who does what, who waits for whom, what it costs. The highest decisions always reach the CEO, who is a person. The design is RFC 0004.

It is built in waves, each usable in Labs before the next: the engine and the engineering path, then product, project and finance, then marketing. The pilot (10.12) measures the most expensive bet, agents delivering code that is accepted at a reasonable cost, as soon as the first wave exists.

• 10.1 Companies, departments, roles and members · M. The data, the API, privacy as in M6, and company.yaml export and import.
• 10.2 Context and rules in layers · M. Company, department, role and member; the most specific rule wins, allowing is an explicit exception; a preview of what a member receives.
• 10.3 Companies in the app · M. The list, creating one, the org chart drawn by the app (drag to change the boss), roles and context editors, the member page.
• 10.4 Members' routines and agent tasks · L. Compiled, agent and hybrid routines per member, company triggers, working hours, concurrency, a queue, and pausing a company, department or member.
• 10.5 Working together · L. Tasks and the board, delegation with a structured handoff and a dossier, drift checks, side questions, asking the boss and waiting until the answer without spending, loop guards.
• 10.6 Meetings, reports and the company's memory · M.
• 10.7 Deciders, autonomy and invariants · M. Jev, a model, the boss, a person, a committee or a cascade; an autonomy matrix per member; the invariants enforced by the host.
• 10.8 Decision levels · M. Levels and criteria per company, the host first and a classifier only for what it leaves open, unsure means up, the CEO directly or with opinions, a simulator.
• 10.9 Costs in layers · M. Attribution to company, department, member and task; budgets in layers; a forecast before hiring; cost per outcome.
• 10.10 Members' own accounts · M. Any connector per member, kinds of account (brand, machine, service, a real person's), grants on company accounts, each service's terms, revoking pauses what depends on an account.
• 10.11 GitHub and coding in a worktree · L. GitHub capabilities for issues, pull requests, reviews, checks and merges; Claude Code, Codex or opencode in a worktree per task, with the sandbox as an option.
• 10.12 The pilot · owner. A project manager and two developers on Pimpo's own repository for two weeks: at least 60% of pull requests accepted without rewriting, a cost per accepted pull request under a configurable cap ($5 by default), no action outside the matrix.
• 10.13 Product owner and project manager · M. Briefs with a source for every claim, deduplicated signals, the roadmap's scoring, accuracy checked after 30 and 90 days; issues with acceptance criteria and standups.
• 10.14 Finance · M. Costs and revenue (Stripe, GitHub Sponsors, read only), the monthly report, anomalies and budget proposals; no money moves.
• 10.15 Media and publishing · L. Video built locally with ffmpeg and the local voices, checks before asking, YouTube (private upload, then publish), LinkedIn, assisted publishing, AI disclosure.
• 10.16 Earned autonomy · S. After a configurable number of approvals without edits in a row (10 by default), Pimpo suggests autonomy for that kind of delivery; a person accepts.
• 10.18 Talking with members, and meetings with the CEO · M. The CEO talks with any agent, also to discuss a question before answering it, and holds meetings with all or chosen agents, as in a real company: the agents answer in turn or when named, the conversation ends in minutes and decisions, and anything said can become a task.
• 10.19 Memory per task, per agent and per company · M. Each task, each agent and the company keep their own memory, written automatically or only after a decider approves, as each company chooses.
• 10.17 Templates and the showcase · M. Software company, marketing agency, online shop, content channel, consultancy and blank; creating a company by describing it; performance; company widgets; an optional public showcase with only what was approved.

Done when the "Pimpo Dev" company runs for 30 days with every department: at least 20 issues born from the product owner's briefs closed by accepted pull requests, 2 tutorials and 12 shorts published, a monthly finance report that matches the invoices, within budget every day, no action outside a member's matrix, no strategic decision taken by anyone but the CEO, and no silent failure.

Where the order differs from the scores#

• Docker (2.3) scored lower than signing and the updater, mainly for build risk. It moves up to M2 anyway: Pimpo is a single Go binary, so the image is small work, and the server audience is a large part of the competitors' users.
• Browser and sandbox (M4) have high user value (the browser scores among the highest) but the highest safety risk of all items. They stay in M4, after the ecosystem, and are designed as RFCs early, so they do not ship as an afterthought.
• Skills (3.2) depend on the sandbox (4.2) for any script they carry. Skills that are only instructions ship in M3; skills with scripts wait for 4.2.
• Subagents, voice, phone node and channels scored lowest: little differentiation and high build or safety risk. They remain on the roadmap for v1.0 because they matter for completeness, not because they win users.

How progress is tracked#

Each item becomes an issue with the roadmap label and its milestone; Status records what is done and what waits on people or time; the CHANGELOG records what shipped. This roadmap is reviewed at the end of each milestone.

Appendix: scores#

Jev (tools/jev/decisions_roadmap.py, 2026-09-29), each from 0 to 3. Total is 2 × value + differentiation + 2 × adoption − build risk − safety risk.

This page is built from the repository's documentation. Improve it on GitHub.