OpenPip - Open Performance Improvement Plan

An agent-first life operations companion that turns your inbox, plans, and career context into safe, reviewable next actions.

Comment

About the project

Inspiration

Most personal AI products begin with a chat box and make the user do the project-management work:

  • decide which tool to open
  • copy context between services
  • remember what is waiting
  • repeatedly ask the assistant to continue

That is backwards. People need help seeing what matters, what an agent has found, and what still needs a human decision (not another complicated control panel to learn).

OpenPip is an agent-first personal operations companion. Its interface is designed to be a calm, readable dashboard of what the agent is doing for you. Voice is a first-class input, but text and manual controls remain available when a person wants them.

What it does

OpenPip connects a person’s existing work and life context: tasks, calendar, inbox, career materials, travel plans, and saved preferences. Then, OpenPip turns that context into bounded, reviewable next actions.

For OpenAI Build Week, I meaningfully extended the pre-existing OpenPip foundation with three connected capabilities:

  • Intelligent Inbox: after inbox data refreshes, OpenPip starts a durable background triage job. It learns from prior handling of similar messages, can clear low-value mail, creates Local tasks for action items, logs appropriate interactions, and drafts replies for human approval. No-reply and transactional senders are excluded from networking records.
  • On-device voice: the microphone uses the browser’s installed on-device language model for transcription when available, then safely falls back to standard browser speech recognition. Read-aloud controls share one reusable component and prefer a local natural voice path, with the accessibility voice as a fallback. Downloaded voice assets are cached in the browser for reuse.
  • Agent Outcomes and Review: after source data is available, a background proposal pipeline reads persisted context and creates grounded, bounded proposals such as: researching companies, running a job search, preparing a trip comparison, or drafting a campaign brief. The user sees these in one source-neutral Review queue. Each item shows whether any external action has occurred, cites the source context, and requires an explicit approval before work starts.

OpenPip does not automatically submit job applications, send draft replies, contact people, book travel, or start a campaign. Approval is a real product boundary: applications remain drafts, replies remain drafts until the user sends them in Inbox, and campaigns can only start when still pending and the user explicitly approves that send.

How it works

The frontend is a Next.js dashboard that talks only to an authenticated proxy. The proxy forwards scoped requests to the Agent service, which uses the project’s existing storage abstraction for durable per-user records. Browser IndexedDB is used only for local cache/resume behavior, never as the source of truth for review decisions, scheduled actions, or external effects.

The Build Week proposal pipeline runs as event-driven background work unlike a scheduled cron task. It reads stored facts, returns only context-backed proposals, persists them, and creates a Scheduled Action only after the user approves. The scheduler records a truthful lifecycle (queued → running → completed or failed) and observes the actual underlying job endpoint before claiming completion. The dashboard polls those real persisted records, so progress is not a cosmetic animation.

How I built it with Codex and GPT-5.6

OpenPip existed before Build Week. This submission is specifically about the meaningful extension built during the Submission Period (documented in the dated commit history).

I collaborated with Codex running GPT-5.6 to:

  1. Map a scattered set of existing inbox, career, campaign, calendar, task, travel, chat, and storage paths into an agent-first outcome model without deleting the existing manual workflows.
  2. Design and implement a durable proposal pipeline, normalized Review aggregation, idempotent approval/rejection guards, source provenance, and real worker-status handling by reusing the project’s proxy, storage, and scheduler infrastructure.
  3. Build and debug browser-native speech behavior, including capability detection, microphone state safety, reusable text-to-speech controls, fallback behavior, and local model asset caching.
  4. Investigate live logs and failures, refine the interface against real behavior, and add focused tests for review aggregation, pending-state guards, idempotency, and worker failure outcomes.

Codex accelerated the implementation and debugging loop, while I made the product and safety decisions: consolidate by outcomes rather than feature modules; keep voice primary without removing manual interaction; preserve the existing system as the source of truth; and require explicit human approval for any consequential action.

Challenges we ran into

  • Avoiding a fake “agent is working” experience. A progress bar that completes independently of an agent request destroys trust. The scheduler now persists each action, monitors the relevant worker endpoint, and only reports completion from a successful result.
  • Making proactive behavior safe. A useful agent should not wait for a prompt, but it also should not take irreversible actions. The proposal pipeline separates permission to begin bounded work from execution, then separates drafting from sending, applying, booking, or contacting.
  • Using on-device AI without destabilizing the browser. Browser model support varies. The voice work uses capability checks, isolates the local voice path, caches its assets, and preserves stable browser accessibility fallbacks.
  • Consolidating the product without deleting capabilities. Career, Inbox, campaigns, planning, tasks, and travel remain usable manual workflows. The agent-first dashboard simply leads with the outcomes across them.

Accomplishments that we’re proud of

  • A complete agent-first journey: dashboard → review queue → specific approval detail, without tabs, sidebars, or faux navigation controls in the new flow.
  • A trustworthy review model where every pending item says what external action has (or has not) occurred, and source context can lead back to the relevant email, calendar event, or saved conversation context.
  • A real durable background pipeline rather than a demo-only animation: persisted proposals, persisted scheduled actions, endpoint-backed progress, idempotent decisions, and failure states.
  • A more natural, privacy-conscious voice interaction that uses on-device browser capabilities first and falls back gracefully.

What we learned

  • Proactive agents feel trustworthy when they expose why a recommendation exists, what will happen next, and where the approval boundary is.
  • Consolidating a product is not the same as removing it. A single outcomes surface can simplify the experience while preserving manual control for people who want it.
  • Durable state and observable real job results matter more than clever loading animations in an agentic product.
  • Codex is most useful as a rapid engineering partner when the human keeps the product boundaries clear: source of truth, approval gates, and what must never happen automatically.

What’s next for OpenPip

  • Add a sanitized demo dataset and hosted judge environment so evaluators can explore without connecting personal accounts.
  • Expand the proposal workers to more user-approved workflows while preserving the same source-citation and approval model.
  • Continue refining the agent-first dashboard from real use, especially voice-first interaction and the wording that helps users understand agent activity at a glance.
  • Broaden test coverage from focused workflow contracts to full service integration tests.

Built With

Share this project:

Updates