DEV Community: SANJEEVA KUMAR SSK

CrisisOps: Turning Disaster Response Experience Into Persistent Operational Memory

SANJEEVA KUMAR SSK — Tue, 29 Sep 2026 15:48:47 +0000

DescriptDescript

Done. I completed and verified the final video render.

Final video:
Download CrisisOps FINAL — Visible Subtitles

Verified:

4:00.43 duration

1080 × 2392 portrait

H.264 video + AAC audio

Subtitles are burned directly into the video

Actual CrisisOps screen recording retained

No fake UI inserted

Subtitle styling is readable on the mobile recording

One remaining limitation: the natural Indian-English AI voice could not be regenerated because the available Descript/HeyGen voice-generation credits are exhausted. The final render therefore retains the existing narration rather than pretending a new Indian voice was generated.

The video itself is now ready to upload/submit.

Today 8:39 PM
What the rest of them how to do

Here are the complete descriptions/content you can use for all the submission fields.

LinkedIn Post — copy this I’m excited to share CrisisOps — Disaster Response Memory Engine, a project focused on helping emergency-response teams turn past operational experience into reusable memory.

During disasters, responders deal with changing conditions, route constraints, resource availability, and information coming from multiple sources. One challenge is that valuable lessons from previous incidents can disappear once an incident is over.

CrisisOps addresses this through a persistent memory loop:

Capture → Retain → Recall → Reflect → Human Decision → Outcome → Future Memory

The system combines operator field reports, public hazard intelligence, and Hindsight persistent memory. When a similar incident occurs, relevant experiences from previous incidents can be recalled and considered during response planning.

For example, a previous North Ward flood scenario records a failed road-delivery attempt caused by an inaccessible route. During a later related incident, CrisisOps recalls that experience and brings it into the response review, giving the operator additional historical context.

The system also incorporates public intelligence from sources including Open-Meteo, USGS, IMD CAP and GDACS, while clearly separating REAL, OPERATOR INPUT, SYNTHETIC, and HINDSIGHT SYNTHESIS information.

CrisisOps is designed as a human-in-the-loop decision-support system. It does not autonomously dispatch responders; the final operational decision remains with the human operator.

GitHub: https://github.com/Sanjeevakumarnani/CrisisOps

The key idea is simple: every incident should help make the next related response better informed.

AI #DisasterResponse #Hindsight #FastAPI #EmergencyManagement #SoftwareEngineering #Innovation #CrisisOps

Article — use this as the article description/content Title:

CrisisOps: Turning Disaster Response Experience Into Persistent Operational Memory
Article:

During an emergency, responders need to make decisions with incomplete and rapidly changing information. They need to understand what is happening now, what resources are available, which routes are accessible, and what has already been tried.

But there is another important source of information: what happened during previous incidents.

Operational experience can contain valuable lessons about failed routes, successful workarounds, resource constraints, and local conditions. If that experience is not retained and made available during future incidents, teams may repeatedly solve similar problems from scratch.

CrisisOps — Disaster Response Memory Engine was built around this problem.

CrisisOps combines public hazard intelligence, operator field reports, structured incident information, and persistent semantic memory. Its goal is to allow a response team to capture operational experience, retain it, recall relevant previous experiences, reflect on them, and use that context during a new response.

The core loop is:

Capture → Retain → Recall → Reflect → Human Decision → Outcome → Future Memory

The Problem
Traditional incident-management systems often focus heavily on the current event. They can show current reports, resources, alerts, and status information, but the operational knowledge created during previous incidents can be difficult to reuse.

Consider a flooding incident where a road-delivery attempt fails because a bridge is closed and the approach becomes inaccessible.

If another flood occurs in the same area later, that previous experience can be extremely useful.

A new response team may otherwise see the second incident as a completely new problem.

CrisisOps treats previous operational experiences as reusable memory.

How CrisisOps Works
An operator can create a field report containing information such as:

affected population

immediate needs

route constraints

available resources

observations from the field

response actions

outcomes

The information is retained in Hindsight with a stable incident identity.

When a related incident occurs, CrisisOps can recall relevant experiences from persistent memory.

The recalled information can then be used during response-plan review.

Hindsight also provides the reflection step, turning recalled operational experiences and the current situation into a focused synthesis for the operator.

The system does not make the final operational decision.

Instead, the operator receives additional historical context before deciding what action to take.

A Demonstration Scenario
The demonstration uses a clearly labelled synthetic North Ward flooding scenario.

The first incident contains 120 affected people, water and medical-support needs, a closed bridge, and an attempted road delivery.

The road approach eventually becomes inaccessible.

That experience is retained in Hindsight.

A second related flooding scenario then occurs with 150 affected people, two boats, one truck, and a closed Bridge 4.

A canal route is being considered.

Instead of considering only the current information, CrisisOps recalls the previous North Ward incident.

The previous road-delivery failure becomes part of the response context.

A third related incident then provides another outcome: the canal route is available, boats are staged at Depot 2, and the canal route is successfully used.

That outcome is retained as another memory.

This creates a simple learning curve:

Previous failure → Recall → New decision context → Successful outcome → New memory

The objective is not to claim that one historical event automatically determines the correct response. Instead, the system makes previous experience available to the human decision-maker.

Hindsight Integration
Hindsight is central to the architecture.

CrisisOps uses three important memory operations:

Retain — stores operational experiences.

Recall — retrieves relevant experiences for a new situation.

Reflect — synthesizes recalled experiences into useful operational context.

A simplified implementation looks like this:

await client.aretain(
bank_id=BANK_ID,
content=incident_memory,
document_id=incident_id
)

memories = await client.arecall(
bank_id=BANK_ID,
query=current_situation
)

reflection = await client.areflect(
bank_id=BANK_ID,
query=current_situation
)
The important distinction is that the system is not simply querying the current database state. It is building persistent operational memory that can be reused across related incidents.

Public Intelligence
CrisisOps also connects to public hazard-intelligence sources including:

Open-Meteo

USGS

IMD CAP

GDACS

The interface deliberately distinguishes different information types.

REAL identifies public intelligence.

OPERATOR INPUT identifies human-entered information.

SYNTHETIC identifies demonstration data.

HINDSIGHT SYNTHESIS identifies memory-based synthesis.

This provenance distinction is important because synthetic demonstration scenarios should not be confused with verified emergency information.

Technical Architecture
CrisisOps uses a lightweight web architecture:

Frontend

FastAPI/Jinja-based interface with HTML, CSS and JavaScript.

Backend

FastAPI with structured Pydantic models and application services.

Database

SQLite for incident and application-state storage.

Persistent Memory

Hindsight for semantic operational memory.

Public Intelligence

Open-Meteo, USGS, IMD CAP and GDACS integrations.

The system also includes deployment configuration, tests, CI validation and live health/smoke checks.

Human-in-the-Loop
Emergency response requires careful boundaries.

CrisisOps is designed as a decision-support system rather than an autonomous dispatch system.

It can provide:

previous incident context

recalled operational experiences

historical route information

lessons from previous outcomes

public hazard information

But the final operational decision remains with the human operator.

This keeps the system focused on helping responders make better-informed decisions rather than automatically taking operational actions.

What We Learned
One of the biggest lessons from building CrisisOps was that persistent memory needs to be visible in the product.

It is not enough to say that an application uses a memory system.

The user should be able to see the difference between a response based only on the current incident and a response that also has access to previous operational experience.

That is why the CrisisOps demonstration focuses on the sequence:

Retain → Recall → Reflect → Outcome → Future Memory

The project also makes an explicit distinction between real public intelligence and synthetic demonstration data.

This makes the demonstration easier to understand and avoids presenting simulated emergency information as verified information.

Limitations
CrisisOps is a prototype and should not be treated as a replacement for official emergency-management systems.

Public intelligence feeds can change availability and coverage.

Synthetic scenarios are used for demonstration and do not represent actual emergency events.

Memory retrieval can also depend on the quality and relevance of previously retained information.

The system therefore keeps the human operator in the decision loop.

Conclusion
CrisisOps explores a simple idea:

Every incident should help make the next related response better informed.

By combining operational reports, public hazard intelligence and persistent Hindsight memory, CrisisOps turns individual response experiences into reusable operational knowledge.

Instead of allowing lessons to disappear when an incident ends, the system provides a mechanism to retain those experiences, recall them during future incidents, reflect on them, and continue building operational memory over time.

GitHub:
https://github.com/Sanjeevakumarnani/CrisisOps

MCP Connects Agents to Tools. A2A Connects Agents to Each Other. Here's Why That Distinction Changes Everything

SANJEEVA KUMAR SSK — Wed, 29 Apr 2026 05:49:04 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

I've spent the past week digging into every major announcement from Google Cloud
NEXT '26. Gemini Enterprise Agent Platform. TPU v8. ADK v1.0 stable. Project Mariner.
There's a lot to love.

But one thing kept nagging me: everyone is building multi-agent systems without
actually understanding the communication layer underneath them.

At NEXT '26, Google made two protocol-level announcements that most keynote
recaps buried in footnotes:

A2A v1.0 is now production-stable, running at 150 organizations, and governed by the Linux Foundation
MCP (Model Context Protocol) is now natively integrated across Google Cloud services (BigQuery, Maps, GKE, Compute Engine)

These are NOT the same thing. They are NOT competing. And if you're building
agents without understanding both, you are going to have a very bad time in production.

Let me explain the difference — and then show you exactly how to use them together.

The Confusion Everyone Has

When Google announced MCP support in December 2025, and then doubled down on
A2A at NEXT '26, a lot of developers asked: "So which one do I use?"

This is the wrong question. Here's a cleaner mental model:

MCP = how your agent connects to tools and data sources
A2A = how your agent communicates with other agents

Think of it like a company:

MCP is the internal tool stack — Slack, Notion, your CRM, your database
A2A is the org chart — who delegates to whom, who can request what from whom

If you only have MCP, your agent is a brilliant solo worker drowning in tasks.
If you only have A2A, your agents can coordinate perfectly but have no tools to
actually do anything.

You need both.

Why A2A v1.0 Matters More Than You Think

The original A2A launch (early 2025) had 50+ partners. At NEXT '26, it's 150
organizations running it in production — not pilots, not proofs of concept.

Microsoft, AWS, Salesforce, SAP, and ServiceNow are all routing real tasks through A2A.

What changed in v1.2 (announced at NEXT '26):

Signed Agent Cards — cryptographic signatures for domain verification, so you can trust the agent you're talking to
Linux Foundation governance — this is no longer a Google protocol. It's an open standard with independent oversight
Native ADK integration — A2A support is now built into Google's ADK, LangGraph, CrewAI, LlamaIndex Agents, Semantic Kernel, and AutoGen

That last point is huge. It means the ecosystem around A2A just became
language-agnostic and framework-agnostic on the same day ADK hit stable v1.0
in Python, Go, Java, and TypeScript.

A Real Example: The Procurement Agent Problem

Here's a scenario I've seen in almost every enterprise I've worked with:

A company has:

A finance agent that knows about budgets and purchase limits
An HR agent that knows about team headcount and contractor approvals
A procurement agent that actually places orders

In the old world, these three systems talk through custom API glue code that
someone wrote in 2023 and nobody fully understands anymore.

With A2A + ADK, the procurement agent can:

Receive a purchase request via MCP (connected to your Slack or email tool)
Use A2A to ask the finance agent: "Is this within budget?"
Use A2A to ask the HR agent: "Is this contractor already approved?"
Get structured responses from both agents
Make a decision and place the order via MCP (connected to your ERP system)

No custom API code. No parsing each system's proprietary response format.
Secure handoffs with signed agent cards. Full audit trail.

Building It: ADK + A2A in Practice

Here's a minimal Python example using ADK v1.0 that shows what this actually
looks like in code:

from google.adk.agents import LlmAgent
from google.adk.tools.a2a import A2AClient

# Initialize the A2A client pointing to your finance agent
finance_agent = A2AClient(
    agent_card_url="https://finance.yourcompany.com/.well-known/agent.json"
)

# Initialize the A2A client for your HR agent
hr_agent = A2AClient(
    agent_card_url="https://hr.yourcompany.com/.well-known/agent.json"
)

# Your procurement orchestrator
procurement_orchestrator = LlmAgent(
    model="gemini-3-flash",
    name="procurement_orchestrator",
    instruction="""
        You handle purchase requests. Before approving any request:
        1. Verify budget availability with the finance agent
        2. Verify contractor approval status with the HR agent
        3. Only proceed if both agents confirm
    """,
    tools=[finance_agent.as_tool(), hr_agent.as_tool()]
)

The agent_card_url points to a JSON file that describes what the agent can do,
what data it accepts, and — in v1.2 — carries a cryptographic signature so you
know you're talking to the right agent.

This is what Google means by "structured and secure" agent-to-agent
communication. It's not agents sending each other free-text messages.
It's a typed, verifiable protocol.

The MCP Side: Connecting to Real Tools

While A2A handles agent-to-agent coordination, your agents still need to
connect to actual tools. This is where MCP comes in.

At NEXT '26, Google launched fully managed MCP servers for:

BigQuery — agents query your data warehouse directly
Google Maps — agents get location intelligence
Compute Engine — agents can provision and manage VMs
Kubernetes Engine (GKE) — agents manage container workloads

Using ADK, connecting to these is straightforward:

from google.adk.tools.mcp import MCPToolset

# Connect your agent to BigQuery via managed MCP
bigquery_tools = MCPToolset(
    connection_params=SseServerParams(
        url="https://bigquery.googleapis.com/mcp/v1",
    )
)

# Your analytics agent now has live BigQuery access
analytics_agent = LlmAgent(
    model="gemini-3-flash",
    name="analytics_agent",
    instruction="You answer data questions using live BigQuery data.",
    tools=[*bigquery_tools.tools]
)

Now combine this with A2A, and your procurement orchestrator from earlier
can delegate data lookups to an analytics agent — which uses MCP to hit
BigQuery — and get structured results back through A2A.

That's the full stack.

The Part I'm Most Excited About (And Most Worried About)

Excited: Agent Gateway.

This was announced quietly at NEXT '26 but it's one of the most important pieces
of the whole system. Agent Gateway is essentially a managed proxy that sits in
front of your entire agent ecosystem. It understands both MCP and A2A protocols
natively, enforces your security policies in real time, and integrates with
Model Armor to block prompt injection attacks before they reach your agents.

Think of it as the API Gateway of the agentic era. You wouldn't expose your
REST APIs without a gateway. You shouldn't expose your agent network without one either.

Worried: The signed agent cards in A2A v1.2 are a step in the right direction
for trust, but key rotation and revocation aren't fully specified yet. In a world
where your finance agent is making real budget decisions, the security model needs
to be as rigorous as your OAuth token lifecycle. This is something the Linux
Foundation governance will need to address fast.

What This Means For You Right Now

If you're building anything with agents in 2026, here's the practical checklist:

1. Stop building custom agent communication layers.
A2A v1.0 is stable. The ecosystem support (LangGraph, CrewAI, LlamaIndex) means
you're not locking into Google. Build to the protocol, not to a vendor.

2. Use managed MCP servers where you can.
Google's managed MCP servers for BigQuery, Maps, GKE, and Compute Engine save you
from running your own MCP infrastructure. Start there.

3. Put Agent Gateway in front of everything.
Even if you're just running a two-agent prototype, get in the habit of routing
through a gateway. Your future production self will thank you.

4. Read the Agent Card specification.
The /.well-known/agent.json format is where A2A actually lives. Understanding
this file — what capabilities your agent advertises, how trust is established —
is the most important 10 minutes you'll spend on agentic architecture this year.

The Underrated Takeaway from NEXT '26

Everyone's talking about Gemini 3.1 Pro. The Vertex AI rebrand. The TPU v8
Sunfish and Zebrafish chips.

But the announcement with the longest tail isn't a model or a chip. It's a
protocol reaching production maturity and independent governance.

A2A v1.0 governed by the Linux Foundation is the HTTP moment for multi-agent
systems. We'll look back at April 2026 the same way we look back at 1991:
the point where the infrastructure became standardized enough for everything
else to be built on top of it.

The platform wars for AI are interesting. The protocol wars are what
actually determine who wins.

Start building to the protocol.

Have you started experimenting with A2A or MCP in your projects?
What's blocking you from moving to production? Drop it in the comments —
I'm curious what real blockers look like out in the wild.