ContextSwitch

Home Page
Architecture
Login Page

Inspiration

Developers today rarely use just one AI tool. One teammate might code with Cursor, another debug with Claude Code, while someone else brainstorms architecture with Gemini.

These tools make individual developers faster, but their context remains isolated. Git remembers what code changed, but not why a decision was made, what approaches already failed, or whether two teammates' AI assistants are making contradictory decisions.

This leads to duplicated work, conflicting implementations, and constant prompt fatigue whenever developers start a new AI session.

That inspired ContextSwitch: a shared memory layer for AI-assisted development teams.

Git merges your code. ContextSwitch merges your team's AI reasoning.

What it does

ContextSwitch creates a living project memory shared between developers and the AI tools they use.

Instead of storing another collection of chat histories, it continuously maintains structured project context including goals, progress, decisions, failed approaches, blockers, open questions, and next actions.

Its core features include:

AI State Reconciliation: New updates are reconciled against the existing project state so completed or outdated tasks don't remain in the team's context.
Cross-Developer Conflict Detection: If one developer using Cursor chooses ChromaDB while another using Claude Code chooses Pinecone, ContextSwitch detects the contradiction and surfaces both decisions for resolution.
Gemini Chat Ingestion: Public Gemini shared conversations can be analyzed to extract decisions, assumptions, risks, failures, and useful technical knowledge.
People-Wise Context: Developers can see what teammates have worked on, what decisions they made, which AI tools they used, and what is currently blocking them.
Portable Context Export: Running cs export generates structured Markdown containing the latest project context, ready to paste into a fresh Cursor, Claude, Gemini, or other AI session.

The goal is simple: developers should be able to switch tools, chats, or teammates without losing the reasoning behind their project.

How we built it

ContextSwitch combines a Next.js web dashboard, Python CLI, FastAPI backend, Google ADK, Gemini, and Google Cloud Firestore.

Developers interact with ContextSwitch either through the dashboard or commands such as:

cs log "Use ChromaDB because Pinecone is too expensive"
cs done "Implemented authentication"
cs blocked "Waiting for API access"
cs export

These updates are sent to our FastAPI backend, where Pydantic v2 schemas validate the data and structured AI outputs.

The agentic reasoning layer is built using the Google Agent Development Kit (ADK). Gemini powers our state reconciliation, knowledge extraction, and semantic conflict detection workflows.

We model project evolution as a continuous state transition:

$$ S_{t+1}=R(S_t,E_{new},H_{recent}) $$

where the current project state is updated using new developer evidence and recent team history.

The resulting state, entries, conflicts, member context, and state snapshots are persisted in Google Cloud Firestore.

For Gemini shared conversations, we use Playwright with headless Chromium to render public share pages and pass their conversation content through our structured extraction pipeline.

The frontend is built using Next.js 16, React, TypeScript, Tailwind CSS, and Google OAuth, giving teams a central dashboard to inspect project state, activity, teammate context, and unresolved conflicts.

Challenges we ran into

One of our biggest challenges was preventing the AI from changing project state based on assumptions. A task should not become "completed" simply because the model thinks it probably happened. We therefore designed the reconciliation workflow around explicit evidence and structured outputs.

Another challenge was semantic conflict detection. Different technical opinions are not always actual conflicts. We needed to identify contradictions that materially affect the shared project state while preserving each developer's reasoning.

Gemini shared-chat ingestion was also challenging because the pages are dynamically rendered. We used Playwright to retrieve the rendered conversation before extracting structured project knowledge.

Finally, supporting multiple teams and projects required carefully structuring Firestore queries so each authenticated user sees only the correct team and project context.

Accomplishments that we're proud of

We're most proud that ContextSwitch works across AI tools instead of trying to replace them.

We built an end-to-end system capable of detecting when developers using different AI assistants make contradictory architectural decisions and surfacing those conflicts before they become implementation problems.

We also successfully built:

Gemini-powered project state reconciliation
Cross-developer semantic conflict detection
Persistent shared project memory using Firestore
Developer and source attribution
Gemini shared-chat knowledge extraction
A developer-friendly CLI
A team dashboard for project context and conflict resolution
Portable project context through cs export

Together, these turn disposable AI conversations into persistent, collaborative engineering knowledge.

What we learned

The biggest thing we learned is that making individual AI assistants smarter isn't enough.

As developers increasingly use multiple AI tools, the bigger challenge becomes ensuring that humans and AI assistants share the same understanding of the project.

We also learned how to build structured agent workflows using Google ADK, how important schema validation is when AI outputs affect persistent application state, and why source attribution is essential in collaborative AI systems.

Most importantly, we learned to treat reasoning and context as engineering artifacts, not temporary chat messages.

What's next for ContextSwitch

Our next step is making ContextSwitch increasingly invisible in the developer workflow.

We plan to build native VS Code, Cursor, and JetBrains integrations that can capture important project decisions without requiring developers to manually log every update.

We also want to introduce continuous repository synchronization so commits, pull requests, issues, and discussions can automatically become evidence for the project's living state.

Another major direction is semantic project memory, allowing developers to search historical decisions and failed approaches across projects. A team could eventually ask: