PlansAroundUs

PlansAroundUs finds plans in one's area, sends reminders to friends, guides people through transportation, and pays for restaurant reservations and tickets, helping people grow closer with friends.

Comment

Plans Around Us

Inspiration

Planning with friends sounds simple until it happens across several private conversations.

One person asks, “What should we do tonight?” Another has dietary restrictions. Someone else wants the safest route. A fourth person needs directions or wants to split the cost. Existing assistants usually treat this as one isolated prompt, forcing everyone into the same group chat and making people repeat their preferences.

We built Plans Around Us, an AI-powered personal coordination agent that works through iMessage. Each person can speak privately with the agent, while the system connects the relevant information into one shared plan.

Our goal was not to build another chatbot. We wanted to explore a more useful model:

What if an AI assistant could coordinate people—not just answer questions?

The result feels like a personal secretary for a group: it discovers activities, recommends food, adds safety context, calculates routes, coordinates participants, supports voice interactions, and demonstrates guarded payments through XRPL Testnet.

What it does

A user can text requests such as:

  • “What fun things are happening near me tonight?”
  • “Where should we get dinner?”
  • “Is this area okay for a late walk?”
  • “How do we get there?”
  • “Plan a fun and safe night near Columbia.”
  • “Send Keith one test dollar.”

The agent determines which capabilities are needed and combines their results into one concise response.

For a complete night-planning request, it can:

  1. Discover nearby events.
  2. Find restaurants that fit the group’s preferences.
  3. provide historical safety context.
  4. Calculate a real walking or transit route.
  5. Coordinate updates across users’ separate conversations.
  6. Optionally demonstrate an XRPL Testnet payment with explicit confirmation.

How we built it

Photon as the communication layer

Photon Spectrum provides the project’s iMessage interface.

Photon receives messages, shared locations, voice memos, sender identities, and conversation context. It is also the only component responsible for sending user-visible iMessage replies.

This lets users interact with the project through an interface they already understand—texting—without downloading another application.

Gemini as the reasoning and orchestration layer

Gemini interprets the user’s request and determines which capabilities are necessary.

Instead of allowing Gemini to invent results, we use it as a grounded orchestrator. It receives structured information returned by our tools and composes a natural response from those results.

Gemini can route requests to:

  • Event discovery
  • Restaurant search
  • Historical safety analysis
  • Route calculation
  • Reservation workflows
  • User-profile lookup
  • Testnet payment workflows

For combined requests, independent tools can run concurrently. Dependent operations, such as calculating a route to a selected restaurant, run afterward.

TigerDB as the operational intelligence layer

TigerDB stores the project’s time-oriented and operational data.

We use it for:

  • Historical NYPD safety information
  • Searchable public-event information
  • Navigation and operational context
  • User identity profiles
  • Display names
  • Public XRPL Testnet wallet addresses
  • Links between users and their personal memory profiles

Each registered user has an operational profile similar to:

user_id
display_name
wallet_address
hashed_photon_identity
memory_profile_reference

A user without a wallet receives the literal wallet value 0.

Raw phone numbers are not placed into Gemini’s context or stored directly in TigerDB. The Photon identity is hashed before persistence.

When Gemini needs to identify a participant or resolve a payment recipient, it receives the sanitized Tiger-backed directory containing names, opaque user IDs, and public Testnet addresses.

DeepSpace as the shared backend

DeepSpace connects individual users to shared plans without requiring them to participate in the same group chat.

It manages:

  • User registration
  • Beta access
  • Channel identity linking
  • Shared plans
  • Plan membership
  • User preferences
  • Notification delivery
  • Cross-conversation coordination

When someone registers, the Node worker pulls their profile from DeepSpace and synchronizes it into TigerDB. The synchronized profile contains their opaque user ID, name, wallet address or 0, and a hashed messaging identity.

This creates a deliberate separation of responsibilities:

  • DeepSpace knows how to privately reach a user.
  • TigerDB provides the operational directory used by the agent.
  • Gemini sees only the minimum sanitized information required to reason.
  • Photon performs the actual iMessage delivery.

Google Maps Platform for factual places and routes

Google Places provides factual restaurant and location candidates. Google Routes provides real travel durations, distances, travel modes, and directions.

Gemini may rank the candidates, but it cannot invent a restaurant, place ID, operating hour, or route duration.

Every routed destination must contain verified coordinates or a valid place identifier. If a route request fails, the system can still return a Google Maps directions link without claiming an unverified travel time.

ElevenLabs for voice interaction

ElevenLabs extends the assistant beyond text.

The system can process voice messages and use voice agents for workflows such as calling a restaurant. This allows the same planning context to move naturally between iMessage, voice input, and outbound calls.

Voice is treated as another interface to the same agent rather than a separate assistant with its own memory and logic.

XRPL Testnet for guarded payment demonstrations

We use XRPL Testnet to demonstrate agent-assisted payments without using real money or banking information.

Before a payment can proceed, the system verifies:

  • The sender is linked to a registered identity.
  • The recipient exists in TigerDB.
  • The recipient has a valid public Testnet address.
  • The amount is within the configured limit.
  • The user explicitly confirms the transaction.
  • The network is XRPL Testnet rather than Mainnet.

The system then returns a transaction hash and explorer link. Private wallet signing material is never stored in TigerDB, DeepSpace, Gemini context, or frontend data.

System architecture

User
  |
  v
iMessage / Voice / Web
  |
  v
Photon Spectrum
  |
  v
Node Agent Worker
  |
  +--------------------+
  |                    |
  v                    v
DeepSpace           TigerDB
Users               Profiles
Plans               Events
Membership          Safety history
Notifications       Wallet directory
  |                    |
  +---------+----------+
            |
            v
       Gemini Router
            |
   +--------+--------+---------+---------+
   |                 |         |         |
   v                 v         v         v
Events             Food      Safety     Routes
NYC Open Data      Places    NYPD       Google Routes
Tavily             API       history    API
   |                 |         |         |
   +-----------------+---------+---------+
                     |
                     v
           Grounded response composer
                     |
                     v
            DeepSpace notification
                     |
                     v
              Photon iMessage

Challenges we faced

Connecting users across separate conversations

The hardest conceptual problem was separating a person’s identity from a chat.

A Photon space represents a conversation, but one person may participate in multiple conversations. Similarly, a shared dinner plan may involve several people who never appear in the same group chat.

We solved this by making the user the primary identity and treating conversations as delivery contexts. DeepSpace maintains plan membership and private channel links, while TigerDB provides the operational directory.

Shared Photon numbers

Photon can assign different messaging numbers depending on the participant. This means the agent cannot assume that every user sees the same public phone number.

We designed registration and onboarding around each participant’s assigned messaging relationship. The backend connects these platform-specific identities to one stable internal user ID.

Avoiding hallucinated facts

A persuasive answer is dangerous if its restaurant, safety statistic, route, or wallet address is invented.

We separated reasoning from evidence:

  • Gemini decides what information is needed.
  • Tools retrieve factual information.
  • Structured contracts carry the results.
  • Gemini composes the response using only returned evidence.

This required stricter interfaces than a typical chatbot, but it made the final system much more trustworthy.

Handling incomplete failures

A city-planning request can involve several APIs. One unavailable integration should not destroy the whole response.

Each tool returns one of three states:

ok
partial
unavailable

The response composer can still present verified results while clearly identifying a missing component. For example, it can recommend a real event and restaurant even if the route provider is temporarily unavailable.

Protecting private identity information

The assistant needs enough identity information to coordinate people, but Gemini should not receive phone numbers or secret credentials.

We separated information by purpose:

  • DeepSpace stores private channel identities.
  • TigerDB stores opaque IDs and hashed Photon identities.
  • Gemini receives names, opaque user IDs, preferences, and public Testnet addresses.
  • Wallet signing secrets remain isolated from all three.

Coordinating a rapidly changing team repository

Four people worked simultaneously on safety, events, food, routing, payments, backend infrastructure, and the frontend.

This led to frequent merge conflicts, especially around the central message-processing loop. We learned to define shared contracts first and keep individual tools isolated. The integration layer owns the chat loop, while individual modules return structured results instead of sending their own messages.

What we learned

We learned that multi-user AI systems require more than a good language model.

The most important work was designing boundaries:

  • Who owns identity?
  • Who owns factual data?
  • Who is allowed to send messages?
  • What information may the model see?
  • What happens when one provider fails?
  • Which actions require explicit confirmation?

We also learned that “memory” and “shared context” are not the same thing. A personal preference may be useful for recommendations without being appropriate to reveal to the entire group. Our architecture keeps personal memory private while sharing only plan-relevant information through explicit structures.

Finally, we learned that an assistant becomes substantially more useful when it can connect separate conversations. The innovation is not simply generating a better response—it is maintaining continuity and coordinating action across people, channels, and services.

What makes Plans Around Us different

Most assistants are designed around one user, one conversation, and one prompt.

Plans Around Us is designed around:

[ \text{Private users} + \text{shared intent} + \text{grounded tools} \rightarrow \text{coordinated action} ]

Each person can keep a private relationship with the agent while still contributing to a shared outcome.

That makes the system useful for more than finding a restaurant. The same model could support:

  • Coordinating families
  • Planning student activities
  • Organizing travel groups
  • Managing accessibility requirements
  • Scheduling volunteer teams
  • Coordinating care networks
  • Handling shared expenses with explicit guardrails

What’s next

Our next steps are to:

  • Expand Android and SMS support using the same channel-neutral backend.
  • Make shared-plan creation fully conversational.
  • Improve user-controlled privacy and preference sharing.
  • Add stronger evaluation of routing accuracy and coordination success.
  • Measure recommendation quality across multiple participants.
  • Add human-readable explanations for why each tool was selected.
  • Expand the test-payment sandbox while preserving explicit confirmation.
  • Study how multi-user agents should handle disagreement, consent, and changing group preferences.

Plans Around Us began as a city-planning assistant, but it evolved into a broader experiment in multi-user AI coordination: one agent, several private relationships, and a shared plan everyone can act on.

Built With

Share this project:

Updates

Submission history