Research Continuity Agent

Product Hero
Agent Review
Updated State v7 + Session Brief
Architecture Diagram

Inspiration

Complex technical research rarely happens in one continuous session.

A researcher may spend one session reading papers, another implementing a prototype, another debugging an experiment, and then temporarily jump into an unexpected side question. The notes usually survive, but the reasoning thread often does not.

When returning later, the difficult questions are not just “What did I write?”

They are:

What have I actually established? What is still only a hypothesis? What evidence is missing? Did this new idea conflict with something I already believed? Am I jumping ahead before resolving a prerequisite? What should I do next?

I encountered this problem directly while working on my own computer architecture research involving Processing-in-Memory, cache coherence, and NoC congestion.

Research Continuity Agent was built to preserve that evolving research state across sessions.

What it does

Research Continuity Agent turns a new research note into a reviewable update to persistent research state.

When a researcher submits a note, the agent:

Retrieves the relevant existing research context. Interprets new Claims, Hypotheses, Questions, Evidence, and Research Artifacts. Compares the new reasoning with the existing state. Detects conflicts, evidence gaps, unresolved dependencies, and premature transitions. Recommends one concrete next action. Creates a structured Proposed Patch instead of directly rewriting the research state. Asks for researcher confirmation when an important state change is involved. Incorporates researcher corrections. Deterministically validates and transactionally commits the accepted update. Generates a Session Brief and resume point for the next research session.

The core interaction model is:

AI proposes. Researcher corrects. System validates. State persists. Research continues.

Real Demo Scenario

The hackathon prototype uses a real research scenario from my thesis work on digital PIM systems.

The persistent state initially contains:

a goal to define the correctness mechanism for non-coherent PIM access to CPU-cached shared data, an existing MESI claim that memory may be stale while a CPU cache holds the newest Modified copy, an unresolved question about what must happen before PIM accesses the shared line, and an active next action to define the correctness flow.

I then submit a new thought:

“I think a non-coherent PIM unit can directly update memory even when the CPU cache holds M state. Coherence traffic may not matter, so I want to measure congestion.”

The agent does not simply summarize or agree with me.

It identifies:

a correctness conflict between direct PIM memory access and the CPU-owned Modified cache line, an evidence gap behind the assumption that coherence traffic may not matter, and a premature transition because I am trying to measure congestion before defining a valid correctness model.

It preserves the unsupported assertions as Working Hypotheses, proposes a new next action, and asks me to review the state changes.

After I correct and accept the proposal, the system commits the patch and advances the project state from version 6 to version 7.

After refreshing the application, the corrected state is still present and becomes the starting point for the next session.

Why it is agentic

Research Continuity Agent is not a single-turn summarizer or a chat interface wrapped around an LLM.

The agent actively:

retrieves relevant prior context, interprets new research reasoning, compares it against persistent state, detects research-level problems, decides when human confirmation is required, recommends a concrete next action, proposes structured state mutations, incorporates user corrections, and resumes future sessions from the accepted state.

Most importantly, Gemini does not receive unrestricted database write access.

The LLM proposes changes.

The researcher reviews them.

Deterministic application code validates them.

Only then is the state committed.

This allows the AI to guide the research process without silently becoming the source of truth.

How we built it

The application is implemented as a single deployed web service.

The frontend sends a research note to a FastAPI backend running on Google Cloud Run.

The backend loads the current Research State and invokes a Google ADK agent backed by Gemini 3.5 Flash.

Gemini returns structured analysis containing:

candidate research items, relationships to prior state, detected issues, a recommended next action, and whether researcher confirmation is required.

The application converts this into a Pending Patch.

The researcher can accept, reject, or correct that patch.

Accepted updates pass through deterministic validation rules before being committed transactionally to Cloud Firestore.

The updated state includes the research items, detected issues, correction history, active next action, project version, and Session Brief.

The next session reloads that committed state instead of relying on the previous chat transcript.

Architecture

Researcher

→ Cloud Run Web Application → FastAPI Research State Service → Google ADK → Gemini 3.5 Flash through Vertex AI → Structured Proposed Patch → Human Review / Correction → Deterministic Validation → Firestore Transaction Commit → Persistent Research State → Next Session Resume

The full architecture diagram is included in the project repository.

Google Technologies Used Gemini 3.5 Flash

Used to interpret research notes, compare new reasoning with retrieved state, detect research issues, and propose a next action.

Google Agent Development Kit (ADK)

Used to implement and execute the Research Continuity Agent workflow with structured model output.

Vertex AI

Provides hosted access to Gemini for the deployed agent.

Google Cloud Run

Hosts the complete FastAPI web application and agent backend.

Cloud Firestore

Stores persistent Research State and provides the transactional commit boundary for accepted patches.

Cloud IAM

Provides least-privilege runtime access from Cloud Run to Vertex AI and Firestore.

Safety and Human Oversight

A major design goal was preventing an LLM interpretation error from silently corrupting persistent research knowledge.

The prototype therefore enforces several invariants:

Raw research notes are preserved. User reasoning is not automatically treated as Evidence. Unsupported assertions remain Hypotheses. Gemini cannot silently overwrite existing validated Claims. Proposed Hypotheses only become Working Hypotheses after acceptance. Only one Next Action can be active at a time. A patch must match the current project version before commit. Rejected proposals never enter active Research State. Firestore commits are transactional. Session Briefs are generated from committed state rather than unapproved model output. Challenges We Ran Into Keeping the product agentic without giving the model unrestricted control

Allowing Gemini to directly mutate persistent research state would have been easy, but unsafe.

The Proposed Patch boundary became the key architectural decision: the model performs semantic reasoning, while deterministic code controls what actually becomes persistent.

Preserving epistemic status

A research assistant must distinguish between something the researcher believes, something supported by evidence, and something still unresolved.

We had to explicitly prevent unsupported technical reasoning from being promoted into validated knowledge.

Structured model failures

During real Gemini testing, one structured response was truncated and produced invalid JSON.

Instead of letting that create partial state, the analyzer now treats malformed structured output as a failed analysis and retries without persisting a partial patch.

Maintaining continuity across real sessions

Persisting chat history alone was not enough.

We needed a compact Research State representing what currently matters: goals, Claims, Hypotheses, Questions, Issues, next action, correction history, and a resume point.

Accomplishments That We're Proud Of

The hackathon prototype completes the full loop using a real research scenario:

Research State v6

→ real Google ADK + Gemini analysis → conflict / evidence-gap detection → Pending Patch → researcher correction → deterministic validation → Firestore transaction → Research State v7 → Session Brief → page refresh / new process → State v7 is still available

The same workflow was also deployed successfully to Google Cloud Run.

The resulting application is not just producing recommendations: the agent participates in an actual persistent workflow while remaining under researcher control.

What We Learned

Persistent memory for an AI partner is more useful when it stores current reasoning state, not simply conversation history.

For research work, remembering previous messages is not enough. The system needs to know what is currently believed, what remains uncertain, what evidence exists, what conflicts are active, and where work should resume.

We also learned that human-in-the-loop design does not necessarily make an agent less agentic.

The agent can autonomously retrieve context, detect problems, and formulate a state transition while still requiring human approval for epistemically important changes.

That division of responsibility made the system both more useful and more trustworthy.

What's Next

The current prototype intentionally implements one narrow vertical slice rather than a complete research platform.

The next steps would be:

richer retrieval across larger research histories, direct links from Evidence to papers, experiment outputs, traces, and code, better detection of changes in epistemic status over time, reusable Research State across different technical research domains, and longer-term adaptation to how an individual researcher evaluates uncertainty and chooses next actions.

A future version could also integrate with a larger visual research workspace, but the core principle would remain the same:

Preserve the reasoning state first. Add more tools later.

Links to Submit

Source Code GitHub repository: Melody-Taiwan/research-continuity-agent

Live Application Cloud Run deployment: research-continuity-agent-qlt5kvshca-as.a.run.app

Architecture Diagram architecture/architecture-diagram.png

Demo Video https://youtu.be/iOvgsn3CPK4