OpenPip - Open Performance Improvement Plan

• 

  Dashboard

• 

  Task Management & Progress Tracking

• 

  Travel Planning

• 

  Trip Results

• 

  Recommendations

• 

  Itinerary & Prep List

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.

Onboarding starts with the Study Me step. 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.

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

• amazon-bedrock-agentcore
• aws-eventbridge-scheduler
• google-oauth2
• mcp
• next.js
• strands-agents-sdk