Harbor Storm

Inspiration

Harbor Storm started as a shipping-weather problem.

I spend a lot of time tracking weather, and I am interested in logistics problems where physical constraints, changing information, timing, and coordination all interact. Small-island freight gave me a concrete version of that problem.

A boat has a schedule, a cargo limit, a landing cutoff, and a weather window that can change while people are still coordinating around the previous forecast.

That immediately creates a deeper problem for AI agents:

What does a useful multi-agent system look like when no model is allowed to simply declare itself correct?

As AI agents become capable enough to interact with real infrastructure, reasoning quality is only part of the problem. An operational system also has to answer:

• Who is this agent?
• What information can it see?
• What infrastructure can it reach?
• Has the world changed since it reasoned?
• Who has final authority to change operational state?

That became the core constraint behind Harbor Storm:

The LLM cannot choose who it is, and it cannot decide what becomes authoritative truth.

I used small-island shipping and marine weather as the first testbed because the constraints are physical and easy to understand.

The weather specialist owns the marine conditions. The shipper owns the manifest. The harbourmaster owns the sailing slots.

None of them can authorize the departure alone.

And while they are coordinating, reality can change.

A plan can therefore be completely correct when it is produced and still be wrong to execute moments later.

That became the failure Harbor Storm is designed around.

I was also interested in systems where useful global behavior comes from many bounded actors responding to local information, shared state, feedback, and constraints rather than one actor controlling everything. Natural systems, transport networks, biological signaling, and decentralized coordination all influenced that part of the design.

But the project increasingly became less about boats and more about a general problem:

How do multiple autonomous agents coordinate safely when the physical world they are operating in keeps changing underneath them?

That is the foundation I wanted to build.

What it does

Harbor Storm is a governed multi-agent operational foundation first demonstrated through a shipping-weather scenario and then transferred to other logistics problems.

HarborWindow

HarborWindow is the original and flagship scenario.

It coordinates three bounded specialists:

• window-agent for marine weather and safe crossing windows
• cargo-agent for manifest weight and vessel capacity
• harbormaster-agent for sailing slots, bookings, and landing cutoff

Their information is genuinely separated.

The weather agent cannot read the cargo manifest or sailing schedule. The cargo agent cannot read the weather. The harbourmaster cannot invent either.

Instead, each actor publishes typed constraints into shared operational state.

The seeded HarborWindow scenario begins with a boat booked to sail at 12:00. Weather makes that departure unsafe. The system rejects it, replans, verifies a safe 14:00 departure, and commits the new operational state.

The harder control happens when a proposal is correct but becomes stale.

The agent can observe revision 0, correctly propose a plan, and then lose the right to commit that plan if the world changes to revision 1 before verification.

correct proposal at revision 0
        ↓
world changes to revision 1
        ↓
proposal becomes stale
        ↓
deterministic rejection
        ↓
no authoritative commit

The proposal was not necessarily wrong.

It was no longer current.

StormSlot

StormSlot is the transfer demonstration.

It uses the same underlying coordination foundation for a different operational geometry:

• transport-agent
• port-agent
• warehouse-agent

The problem changes from coordinating a weather-sensitive boat departure to coordinating movement between a port, truck, and warehouse.

The underlying machinery does not change.

The same bounded actors, claims, constraints, revisions, deterministic verification, fencing, authoritative state, and event trace still apply.

StormSlot exists because I wanted to know whether I had built a harbor workflow or whether I had built something transferable.

The transfer worked.

That is important to the larger direction of the project.

ReliefRun and ReliefFleet

The project then moved beyond shipping.

I began adapting the same coordination substrate to disaster logistics through ReliefRun and ReliefFleet.

Instead of a boat departure, the system now deals with things such as:

• changing hazard conditions
• vehicle capacity
• road access
• hospital beds
• convoy departure windows
• multiple missions competing for limited resources
• weather observations arriving over time

The live ReliefRun service has been running against real Himalayan weather with scheduled re-observation.

During that run, the system repeatedly re-verified a standing mission as conditions changed.

At 12:00 local time, the scheduler delivered a routine observation and the verifier detected that the currently committed departure had just become invalid:

departure 12:00 has passed (now 12:00)

The system revoked the old commitment and selected a later valid departure without a human triggering the event.

That is the same invariant HarborWindow was built around, now happening under real time:

A proposal can be correct and still lose the right to become true because the world changed.

The authority model

I separated four things that are often collapsed into the word "agent."

Reasoning authority

Gemini can observe, reason, coordinate, and propose.

The managed actor receives exactly five model-facing tools:

claim_work
read_facts
report_constraint
propose_plan
read_trace

There is no verify or commit tool exposed to the model.

Infrastructure authority

The managed path uses Google Agent Runtime and Google-issued Agent Identity.

Agent Gateway, Agent Registry, IAP, and IAM determine what that identity can reach.

I first demonstrated managed actor execution and governed egress independently so each boundary could be tested clearly.

I then converged them onto a single managed Reasoning Engine.

The final managed path runs Gemini 3.5 Flash inside Agent Runtime while the same engine is bound to Agent Gateway and governed by Google infrastructure.

Captured Gateway evidence includes allowed model-plane, telemetry, and Firestore traffic.

The infrastructure, not the model, determines what the identity can reach.

State-transition authority

A model proposal becomes a CandidatePlan.

Before anything changes, deterministic code checks the current revision, fencing, and operational constraints.

Only the verifier can promote a candidate into authoritative state.

Operational truth

Cloud Firestore holds authoritative operational state.

A model answer, memory, trace, or candidate plan does not become true merely because the model produced it.

How I built it

I wrote Harbor Storm in Python using Google Agent Development Kit and Gemini 3.5 Flash.

The submitted Google Cloud path uses:

• Vertex AI
• Agent Runtime
• Agent Identity
• Agent Gateway
• Agent Registry
• Cloud Firestore
• Google Weather API
• Identity-Aware Proxy
• Google Cloud IAM
• Google Cloud Network Security
• Google Cloud Network Services
• Cloud Logging
• Cloud Run
• Cloud Scheduler

I built the system in layers so model reasoning, infrastructure permissions, deterministic authority, and operational state could be tested independently.

The deterministic path is reproducible offline. A reviewer can clone the repository without a Google Cloud account and run the scenarios, mechanical gates, and test suite.

The managed path proves the Google infrastructure with real model execution:

• Gemini 3.5 Flash executing inside Agent Runtime
• Google-issued Agent Identity
• bounded model tool access
• Agent Gateway-governed execution
• selective IAP authorization
• live Google Weather input
• deterministic verification
• authoritative Firestore state
• Google-side logging and trace evidence

I deliberately kept deterministic verification independent of live providers. The architecture should remain testable even if an external API or managed service is temporarily unavailable.

The state layer also handles distributed-systems problems that appear once several actors operate asynchronously:

• stale observations
• duplicate events
• concurrent claims
• retries
• superseded workers
• contention
• fencing
• idempotency
• revision-bound proposals

I used AI coding and review agents as engineering collaborators, but kept implementation and verification separate.

Important claims were checked against committed SHAs, repository artifacts, live Google Cloud state, and independent reruns rather than accepted because another model said they were true.

Challenges I ran into

Proving identity instead of assuming it

Google Agent Identity is distinct from surrounding infrastructure service accounts.

That forced me to prove identity through control-plane readback and actual IAM behavior instead of trusting ordinary runtime metadata.

Separating registration, transport, and authorization

Agent Registry, Gateway routing, IAP, and endpoint IAM initially looked like one security concept.

They are not.

A destination can be registered without the caller being authorized to reach it.

The same identity can traverse the same governed infrastructure and receive different outcomes based on destination policy.

Building clean allowed, denied, and unregistered comparisons made that boundary much clearer.

Converging the managed execution path

I initially proved managed Gemini execution and governed egress on separate Reasoning Engines.

That was useful for isolating the controls, but it also exposed the next architectural requirement: the actor itself needed to execute through the governed path.

I eventually converged those proofs onto Engine C, where the managed actor executes end-to-end on a Gateway-bound Reasoning Engine while deterministic verification still controls what becomes authoritative.

Handling a world that changes while agents are reasoning

The stale-plan problem turned out to be one of the most important parts of the project.

An agent can make a perfectly reasonable proposal using the state it observed.

That does not mean the proposal should still execute later.

Binding proposals to world revisions turned freshness from a recommendation into a structural invariant.

Making time part of operational truth

The live disaster-logistics work exposed another version of the same problem.

Even if the forecast does not change, time does.

A departure that was valid at 11:30 may no longer be executable at 12:00.

I therefore made the current clock part of the observation identity and deterministic verification logic.

This allows time itself to invalidate an operational plan.

Keeping model capability separate from authority

It is tempting to solve agent problems by giving the model another tool.

I deliberately went in the opposite direction.

Gemini can do the flexible part: interpreting information, reconciling constraints, and proposing a plan.

The model cannot call the functions that verify or commit that plan.

That boundary had to survive both the application design and the actual outgoing model tool surface.

Proving claims was harder than making claims

Independent verification repeatedly found places where technically plausible wording was slightly stronger than the evidence.

Examples included IAM claims that were too absolute, evidence artifacts being cited for events they did not contain, assumptions about tracing, documentation that lagged behind the final architecture, and a live seismic adapter whose requested lookback window was not initially being sent to the upstream API.

Those findings were fixed and converted into stronger tests or narrower claims.

That became one of the most useful lessons of the project:

Evidence needs its own verification boundary too.

Accomplishments I'm proud of

I am most proud that Harbor Storm does not depend on trusting the model to behave correctly.

The important boundaries are enforced outside the model.

A real Gemini 3.5 Flash actor executes inside Google Agent Runtime while receiving only five bounded tools.

Google Agent Identity gives the managed runtime a platform-issued identity.

Agent Gateway, Agent Registry, IAP, and IAM constrain the infrastructure that identity can reach.

The deterministic verifier can reject a proposal even when the model reasoned correctly, because the proposal was created against an older world revision.

Firestore records authoritative operational state independently of what the model says happened.

I am also proud that the original split managed proofs were successfully converged.

The final Engine C path combines managed Gemini execution and Gateway governance on the same Reasoning Engine while retaining the older isolated proofs as evidence of how each control behaves independently.

I am especially proud of the live ReliefRun trace.

The service operated unattended against real Himalayan weather while Cloud Scheduler repeatedly re-observed and re-verified its standing mission.

At sequence 135, ordinary passage of time invalidated the committed departure, the deterministic verifier revoked it, and the system selected a later valid window.

Nobody staged that event.

The clock itself changed the world.

The project is also reproducible.

The current local suite reports:

315 passed
47 skipped without the Firestore emulator

HarborWindow: 5/5 mechanical gates
StormSlot: 5/5 mechanical gates

With the Firestore emulator enabled:

362 passed
0 skipped

The seeded demonstrations are deterministic, and both HarborWindow and StormSlot expose rejection, replanning, verification, and commit directly in their traces.

I also froze the verification core before building later managed-cloud and operational layers around it. That gave me a fixed reference point while the project continued growing.

Finally, I am proud that the project changed direction as I learned what the underlying architecture could actually do.

It started with a boat and a weather window.

StormSlot showed that the same machinery could move into another logistics system.

ReliefRun and ReliefFleet began moving it into disaster response.

That made the larger possibility much clearer.

What I learned

The biggest lesson is that model intelligence and operational authority are different variables.

A capable model can still be:

• looking at stale information
• outside its information scope
• outside its network permissions
• making a proposal that violates a deterministic constraint
• operating from an obsolete plan
• or simply not authorized to make a state transition

The architecture eventually compressed into:

Gemini
= reasoning and proposal

Agent Identity + Gateway + IAM
= infrastructure authority

deterministic verifier
= state-transition authority

Firestore
= operational truth

I also learned that multi-agent coordination does not require giving one model universal visibility.

Bounded actors can coordinate through shared environmental state while retaining narrow information and action scopes.

The useful behavior is not located entirely inside one agent.

Part of the system's intelligence lives in the interaction between:

• bounded actors
• persistent shared state
• changing external conditions
• resource and information constraints
• identity
• permissions
• verification
• feedback

The most important conceptual result for me is still:

A proposal can be correct and still lose the right to become true because the world changed.

That distinction becomes increasingly important as autonomous systems run for longer periods in environments that do not stay still.

What's next for Harbor Storm

Harbor Storm started with shipping and weather.

I do not think that is where it ends.

StormSlot was the first deliberate transfer test. It showed that the same foundation could move from a weather-sensitive harbor departure into a different logistics network without rebuilding the coordination machinery around the new domain.

The direction I want to keep pursuing is disaster-response coordination.

Recent disasters, including the recent disaster in Nepal, keep showing the same underlying problem at a much larger and more consequential scale.

During a disaster, many forms of operational truth can change at once:

• weather
• flooding
• landslides
• road and bridge access
• safe travel windows
• hospital capacity
• shelter capacity
• available vehicles
• fuel
• food, water, and medical supplies
• communication links
• affected populations
• rescue priorities
• geographic hazards

A rescue or delivery plan can be correct when it is created and obsolete minutes later.

That is almost exactly the problem Harbor Storm was built to handle.

The harbor scenario therefore looks to me less like the final application and more like the smallest useful version of a broader system.

I have already begun moving the architecture toward disaster logistics and multi-mission coordination through ReliefRun and ReliefFleet, but I do not consider that a finished disaster-response product.

It is a foundation.

A real system would need much more:

• continuous weather and hazard tracking
• GIS and changing road-network state
• flood, landslide, seismic, and terrain information
• hospitals and shelters
• supply inventories
• vehicles and crews
• satellite, drone, sensor, and field reports
• uncertainty and conflicting observations
• intermittent communications
• regional and cross-agency coordination
• many simultaneous missions
• changing priorities
• persistent operation over days or weeks

The recent Nepal disaster is only the latest example of why I think systems like this are worth working on. More situations are emerging where physical conditions evolve quickly and coordination has to keep adapting with them.

My next step is therefore not to add more harbor-specific features.

I want to keep turning this foundation into a much more complete disaster-tracking, weather, logistics, and coordination system.

The larger goal is a system where many specialized agents can continuously observe different parts of a changing physical environment, coordinate resources through shared authoritative state, revise plans as conditions change, and still remain bounded by identity, permissions, and deterministic verification.

Harbor Storm is not that full system yet.

It is the base I intend to keep building from.

The broader question behind the project is now:

How can autonomous agents help coordinate a rapidly changing real-world disaster without any one agent becoming the unquestioned source of identity, authority, or truth?

Built With

• agent-gateway
• agent-identity
• agent-registry
• agent-runtime
• artifact-registry
• cloud-build
• cloud-firestore
• cloud-logging
• cloud-run
• cloud-scheduler
• fastapi
• gemini-3.5-flash
• github
• google-agent-development-kit
• google-cloud
• google-cloud-iam
• google-cloud-network-security
• google-cloud-network-services
• google-weather-api
• identity-aware-proxy
• pytest
• python
• usgs-earthquake-api
• vertex-ai