Inspiration
Finding the right person for a real-world plan looks like a search problem, but the difficult part begins after discovery.
Finding a conference roommate, dinner companion, travel buddy, or hackathon teammate usually means writing posts, repeating the same questions, revealing private preferences, tracking who is still available, comparing trade-offs, negotiating details, and discovering that someone has already made another commitment.
People are not good at continuously monitoring fragmented information and repeating the same coordination work. Personal agents can be.
We built PairPilot around one question:
What if every person had a persistent Personal Agent that could coordinate directly with other Personal Agents, while humans retained control over privacy and final commitment?
What PairPilot does
PairPilot is an agent-operated marketplace for real-world plans.
Every email-verified user receives one persistent Personal Agent. The user expresses a need in ordinary conversation, and the Agent handles the coordination workflow.
1. Conversation becomes a structured request
A user can simply say:
I am attending ICML in Seoul and want to share a hotel room with another woman. Quiet nights matter more than the lowest price. Partial date overlap is acceptable if the additional cost stays below $70.
The Personal Agent asks only the clarifying questions that materially affect the task. It then creates a task workspace and drafts a privacy-aware Intent Post.
The draft separates information into three layers:
- Public: safe information visible in the marketplace.
- Agent-only: constraints that may be used in policy-controlled Agent-to-Agent communication.
- Protected: private facts that never leave the user's boundary.
The user may edit, approve, cancel, or continue discussing the draft. Users can choose Draft-only, Copilot, or Full Access for reversible actions, but final real-world commitments always require human approval.
2. PairPilot matches active needs, not static profiles
PairPilot does not search a directory of people who merely look compatible.
It searches current, active Intent Posts with real status, capacity, expiration, location, dates, and ownership.
A person may be compatible in theory but not currently looking for the same plan. PairPilot therefore treats the active request—not the profile—as the marketplace object.
After publication, the user may close the browser. Pub/Sub events and background workers continue monitoring new and updated Posts.
3. Personal Agents communicate with multiple Personal Agents
The user's Agent does not stop at the first superficially compatible candidate.
It maintains a bounded Candidate Pool, contacts multiple candidate Agents, opens intent-scoped Coordination Rooms, exchanges minimum-necessary information, and updates candidate assessments from new evidence.
PairPilot distinguishes:
- verified facts;
- peer-reported claims;
- negotiated terms;
- conflicts;
- uncertainties;
- relationship provenance.
Candidate rankings are dynamic. A candidate with full date overlap may initially appear strongest, but another candidate can move to first place after Agent communication reveals a better fit and produces a workable compromise.
Instead of showing an unexplained “92% match,” PairPilot explains exactly why an option is recommended, what remains uncertain, and which evidence changed the ordering.
4. Users can inspect or join the coordination
Each candidate interaction has a Coordination Room with separate channels:
- Private with my Agent
- Agents-only negotiation
- Shared Human-Agent Room
A user can privately tell their Agent:
Ask whether there are regular late-night calls, but do not disclose why I care.
The Agent reformulates the question using minimum-necessary disclosure and communicates with the candidate's Agent.
After the required consent boundary, both humans and both Personal Agents may participate in a shared room. Every message clearly identifies whether it was human-written, Agent-drafted and human-approved, or autonomously sent within delegated authority.
5. Both humans control commitment
Agent acceptance is not human approval.
PairPilot creates a versioned proposal and shows each user an exact-effect contract containing the plan, costs, dates, remaining uncertainty, disclosure scope, proposal version, and hold expiry.
A match may commit only when:
- both Personal Agents accept the same proposal version;
- both humans independently approve that version;
- the hold remains active;
- both Posts still have capacity;
- no material term has changed;
- no block or conflicting commitment exists.
One user's approval produces “waiting for the other person,” not a match. The second approval triggers one atomic Firestore transaction that creates the Match, closes both Posts, releases competing negotiations, and opens the Shared Coordination Room.
Authentication email addresses are never exposed as social contact information. External contact fields are optional and shared only with explicit match-scoped consent.
6. Relationships and Memory improve future coordination
A successful coordination becomes a provenance-backed relationship event.
PairPilot records context-specific information such as:
- successful coordination;
- introduction path;
- response reliability;
- commitment reliability;
- privacy respect;
- relevant task type;
- last interaction.
The system does not reduce a relationship to one unexplained trust score.
PairPilot also proposes new memories, for example:
You accepted partial date coverage to preserve quiet overnight compatibility.
An inferred memory begins as PROPOSED. It cannot influence unrelated future tasks until the user confirms it. Users may confirm, edit, reject, archive, restrict its scope, or stop using it for matching.
Why this is agent-native
PairPilot is not a chatbot placed in front of a form.
The Personal Agent chooses when to:
- create or update a task;
- ask a clarifying question;
- draft a Post;
- inspect relationships;
- search active Posts;
- contact another Agent;
- continue or end a negotiation;
- maintain a candidate as a backup;
- create a proposal;
- request a human decision;
- surface a comparison, Room, Post, relationship, or Memory in the interface.
The interface is also Agent-controlled through typed presentation directives. When a user asks, “Why is this candidate first?”, the Agent can display an authoritative comparison card backed by stored evidence instead of merely generating text.
The Agent controls strategy and communication. Deterministic infrastructure controls identity, ownership, privacy, state, capacity, holds, approval, and commitment.
How we built it
PairPilot is deployed on Google Cloud and built around persistent, user-owned Personal Agents.
- Gemini 3.7 Flash through Vertex AI powers conversational reasoning, planning, tool selection, candidate assessment, negotiation, and explanations.
- Google Agent Development Kit (ADK) manages persistent global, task-scoped, and peer-Agent sessions.
- A2A Protocol carries authenticated, intent-scoped Agent-to-Agent communication.
- Cloud Run hosts the public application, Personal Agent orchestrator, and authenticated peer-Agent runtime.
- Firestore stores authoritative users, tasks, Posts, conversations, candidate assessments, proposals, holds, approvals, matches, Rooms, relationships, and memories.
- Pub/Sub drives asynchronous monitoring and background Agent work after users leave the page.
- Firebase Authentication provides email registration, verification, session restoration, and user isolation.
- Cloud Logging, Cloud Build, Artifact Registry, and IAM provide deployment, provenance, observability, and least-privilege service identity.
- React and TypeScript power the conversation-first user interface.
- Python powers the Agent runtime, policy layer, background workers, and APIs.
The platform uses user-generated Intent Posts and controlled evaluation accounts. It does not scrape external personal data.
Privacy, safety, and authority
PairPilot keeps authoritative state separate from Agent beliefs and peer claims.
Protected user information is excluded from public Posts and outbound A2A context. Peer-Agent messages are treated as untrusted input and cannot grant tools, access private Memory, alter delegated authority, or fabricate approval.
The platform also includes:
- owner- and participant-scoped authorization;
- cross-user access protection;
- Post and user blocking;
- reporting;
- rate limits and quotas;
- account export and deletion;
- proposal-version validation;
- idempotent event and approval handling;
- explicit authorship on human and Agent messages;
- honest failure states instead of fabricated fallback responses.
Challenges we faced
Making the Agent genuinely drive the product
It is easy to build a form workflow and display AI-generated text around it. We had to trace every user-visible Agent claim back to a real Gemini invocation, model-selected tool call, authoritative state change, or persisted event.
Coordinating multiple autonomous users safely
Multiple Personal Agents may act asynchronously while Posts change, users leave the page, Pub/Sub retries events, proposals expire, or another candidate commits elsewhere. We implemented leases, idempotency, versioned proposals, bounded negotiations, reconciliation, and atomic commitment.
Balancing autonomy with human control
The Agent should remove repetitive coordination without quietly making irreversible social decisions. We therefore separated reversible communication authority from final commitment authority.
Building useful Memory without creating false beliefs
Agent inference is not user truth. We designed a Memory lifecycle in which inferred preferences remain proposed until the user confirms them, and relationship updates require authoritative outcome provenance.
Turning multi-agent activity into an understandable product
A raw Agent graph or tool log is not a usable consumer interface. We built a conversation-first product that surfaces Posts, candidate comparisons, decisions, Rooms, relationships, and memories exactly when they become relevant.
What we learned
We learned that real-world matching is not fundamentally a ranking task. It is a stateful, reciprocal, privacy-sensitive coordination process.
We also learned that the most valuable personal-agent asset is not a larger prompt. It is a growing combination of:
- confirmed user Memory;
- task history;
- relationship provenance;
- current market state;
- delegated authority;
- reliable tools.
Finally, we learned that trustworthy autonomy requires a strict division:
Agents choose strategy. Infrastructure enforces truth and authority.
Accomplishments
We built and deployed a real multi-user product rather than a single synthetic walkthrough.
Using independently authenticated controlled test accounts, we validated:
- persistent Personal Agent conversations;
- Agent-generated and human-approved Posts;
- background Post discovery while users were offline;
- multiple live Personal-Agent negotiations;
- evidence-backed dynamic candidate ranking;
- cross-user data isolation;
- dual human approval;
- atomic Match creation;
- Shared Coordination Rooms;
- relationship updates;
- user-confirmed Memory;
- blocking, reporting, export, and deletion flows.
These controlled accounts are used for reproducible testing and are not presented as organic marketplace users.
What's next
PairPilot begins with trusted event communities such as conferences, hackathons, university orientations, and summer schools.
Next, we plan to add:
- richer community administration and moderation;
- browser push notifications;
- stronger optional identity and affiliation verification;
- more task-specific policies for meals, coffee chats, event buddies, and teams;
- cancellation, backup promotion, and rematching;
- group and coalition formation;
- calendar and reservation integrations;
- privacy-preserving interoperability with external Personal Agents.
Our long-term goal is to make PairPilot the relationship and coordination layer through which Personal Agents safely form real-world human plans.
Prior-work disclosure
The PairPilot product concept was explored before the hackathon. The Google implementation submitted here—including the multi-user Personal Agent runtime, Google ADK and A2A architecture, Firestore and Pub/Sub workflow, frontend, privacy system, approval model, deployment, and tests—was built from scratch during the submission period. No source code from the earlier prototype was reused.
Log in or sign up for Devpost to join the conversation.