OpenPip - Open Performance Improvement Plan

Your AI assistant that now picks up the phone: it calls to confirm or reschedule appointments so you don't have to.

Comment

Inspiration

OpenPip stands for Open Performance Improvement Plan. It is a personal operations layer for solo professionals, consultants, founders, and small-business owners who manage their own inbox and calendar.

The problem is not one huge task. It is the steady stream of small decisions: deciding which messages matter, remembering a follow-up, noticing a schedule conflict, and figuring out the right way to resolve it. OpenPip is designed to be judged by how little the user has to open it, not by how much chat it produces.

What it does

OpenPip connects to the user's chosen Gmail, Calendar, Tasks, Contacts, and Drive context. It works in the background and surfaces a concise daily briefing or a proposal when a real decision is needed.

The first onboarding step is Study Me. It reviews historical records one date at a time, creates a compact resumable index, and extracts durable memories such as preferences, routines, work history, documented personal context, shopping or appointment cadence, and other facts that make future assistance more useful. The index stores source references, status, and very brief key facts. It does not store raw messages or documents. The agent can re-read an individual source when it needs precision.

Those memories are available to chat, inbox triage, proposals, and the daily briefing. The inbox agent can draft replies and create tasks. The proposal pipeline cites the source that triggered each action and waits for explicit approval before sending, scheduling, modifying, or calling.

CALL-E is used only for appointment changes that actually require a phone call. After the user approves the proposal, the executor places the call and records the structured result. A calendar event changes only if the call succeeds and the new time is confirmed. Failed, declined, or unconfirmed calls leave the original event unchanged.

CALL-E submission details

CALL-E is not a decorative integration or a generic "AI that makes phone calls" feature. It is one bounded execution path inside OpenPip's existing proposal and review workflow: use the phone only when the appointment context genuinely requires it.

  1. Read evidence, do not call. The proposal scan reads bounded Gmail, Calendar, Tasks, and Contacts signals. It preserves the exact source reference. For an appointment change, it first checks durable channel memory, a booking link/provider, and a directly matched email address. It chooses CALL-E only when there is no usable booking or email workflow, the source contains an explicit phone number, and the requested change can be stated as one bounded goal.
  2. Create a source-linked proposal. OpenPip creates a call_task proposal containing the source id and title, recipient, E.164 phone number, reason, existing appointment context, proposed time, and a structured result schema. Creating this proposal never places a call. The Review queue shows the user the proposed channel, the source evidence, the masked number, and the exact goal.
  3. Require human approval. The call is not executable from the scan or from the agent's suggestion. A user must approve the specific proposal. The approval executor is the only path that can reach the CALL-E adapter, and it passes the stable proposal id as the idempotency key so an approval retry cannot create a duplicate call.
  4. Invoke CALL-E from the backend. After approval, backend/src/openpip_backend/calle.py sends one authenticated request to the allowlisted CALL-E Developer API at https://api.heycall-e.com/v1/calls. The request carries the bounded task, the exact recipient phone, region/locale when known, a result schema, and the OpenPip proposal id as metadata. The adapter polls the returned call id until CALL-E reports a terminal state.
  5. Return a structured outcome. The result distinguishes confirmed, rescheduled, needs_reschedule, declined, no_answer, and unclear, with an optional requested new time. Silence, voicemail, an unclear answer, rejection, timeout, or schema drift remains unresolved and is routed to a human; OpenPip does not infer success or silently redial.
  6. Keep calendar writes behind the same boundary. A Calendar event is updated only when CALL-E reaches a successful terminal state and the structured outcome confirms or reschedules the appointment. Declined, no-answer, unclear, failed, or unconfirmed calls leave the original event unchanged. Any follow-up mutation remains auditable in the proposal/review flow.

The reusable version of this pattern is contributed separately to the CALL-E community repository as the email-task-call-proposal Agent Skill: https://github.com/CALLE-AI/awesome-phone-call-agents/pull/520. The OpenPip-specific adapter remains in this project; the PR contains the portable skill, safety rules, proposal/result contract, and README entry.

Demo boundary

The public demo at https://demo.openpip.me is intentionally a no-login, no-call walkthrough. It does not connect to a user's Google workspace or place a real phone call. It demonstrates the product surfaces and approval-oriented interaction safely.

The actual CALL-E path is implemented in the connected OpenPip deployment and requires an authenticated workspace, an authorized CALL-E account, and an explicitly approved source-linked call proposal. The project video and the linked reusable skill document the integration; the public walkthrough should not be mistaken for an uncredentialed live-call console.

How we built it

  • An Express and HJS frontend provides Today, Review, Settings, Contacts, chat, and onboarding views without a maze of navigation.
  • A FastAPI service hosts the Strands agent, Google OAuth/session context, deterministic background pipelines, memory processing, proposals, review, and approved execution.
  • Strands Agents SDK and Amazon Bedrock models power the agentic passes. Deterministic code handles date pagination, retries, recovery, and approval state.
  • Provider adapters connect Gmail, Calendar, Tasks, Contacts, and Drive. Durable memories and channel context are stored in visible Drive-backed records with stable keys and evidence.
  • The connected application runs as frontend and backend Docker container.
  • The CALL-E adapter runs behind the same approval executor, so phone calls do not bypass the application's safety boundary.

Real challenges and decisions

AgentCore was not the right application boundary

We evaluated Amazon Bedrock AgentCore and explored what a deployment would require. AgentCore is a reasonable runtime for a self-contained agent, but OpenPip is not only an agent invocation. Its pipeline combines deterministic daily crawling and recovery, an agentic memory pass, per-user Google OAuth, proposal and review state, and approval-gated provider actions.

Moving the Strands agent into a separate AgentCore runtime would require an additional invocation wrapper, identity and session handoffs, duplicated coordination, and extra state transfer between the FastAPI application and the runtime. That would make the historical pipeline less customizable and less efficient, while weakening the shared context needed to decide whether an action is safe. We kept Strands inside FastAPI with Bedrock as the model provider. This was an application-fit and efficiency decision.

The first historical crawl design did not scale

Our first instinct was to build a large archive manifest by downloading years of records up front. That was wasteful, consumed storage, and made recovery harder. We replaced it with boundary probes that record only oldest and newest dates, then process one date at a time.

The metadata file contains pointers such as oldestDate, newestDate, currentDate, and recovery state. Each date file stores only the source id, date, reference, brief summary, and completion status. Temporary fetch failures are retried. Recovery resumes from currentDate and retries unfinished records rather than restarting the archive.

Empty memories must be a valid starting state

The memory agent initially encountered a tool error when the memory directory returned null because no memories existed yet. The agent then repeated searches instead of saving the first valid insight. The tool contract now treats an empty result as an empty collection, so the agent can create the first memory, search for related evidence, and upsert a changed fact into the existing memory instead of creating duplicates.

External actions need a human checkpoint

It was important to keep the agent useful without letting it silently send email, change calendars, or place calls. Every external action becomes a source-cited proposal. Approval is the execution boundary. CALL-E is intentionally narrow: it handles phone-required appointment rescheduling, while email, booking-system, and direct Calendar workflows remain separate.

Current status

OpenPip is published. The connected app, public landing page, no-login demo, repository documentation, architecture diagram, and demo video are complete.

Built With

Share this project:

Updates

Submission history