DEV Community: Michael Neang

My AI Agent Didn’t Break. Its Tool Did.

Michael Neang — Mon, 31 Aug 2026 02:57:26 +0000

I created this piece of content for the purposes of entering the All Things Agentic Hackathon.

A lot of agent demos assume the world around the agent stays still.

The prompt is the same. The tools are the same. The API behaves the same way every time.

Real systems do not get that luxury.

A provider can rename a field, restructure a response, change an enum, switch units, or change the behavior behind an operation. The agent itself may be completely fine, but suddenly it can no longer complete the job it completed yesterday.

That was the idea I kept coming back to while building ToolSuture:

What if I repaired compatibility around the deployed agent instead of rewriting the agent itself?

That became the project.

The failure I wanted to reproduce

Most discussions about agent reliability start inside the model:

Did it hallucinate?
Did it call the wrong tool?
Did it plan badly?
Should it retry?

Those are important problems, but I wanted to look at a different one.

What happens when the agent is still correct and the tool changes underneath it?

For the main ToolSuture scenario, I froze a Google ADK shipment agent that expects a v1 provider contract.

Then I changed the provider.

The v2 tool still represents the same underlying shipment capability, but the contract is different enough that the original agent no longer understands it correctly.

The usual answer would be to update the integration and redeploy the agent.

I wanted ToolSuture to try something else.

Recover the capability, not the agent

ToolSuture runs a recovery loop:

Observe → Diagnose → Policy → Plan → Validate → Repair → Replay → Verify

It starts with the original mission, the old tool contract, the new tool contract, provider semantics, and runtime evidence.

Then Gemini 3.6 Flash through Vertex AI handles the part I did not want to reduce to a pile of string comparisons:

Do these two contracts still mean the same thing for this mission?

That matters because schema similarity and semantic equivalence are not the same thing.

If the migration is still semantically equivalent, ToolSuture creates a bounded compatibility repair around the frozen agent.

It does not rewrite the agent.

It then replays the original mission against the changed provider and checks whether the recovered workflow actually worked.

The primary demo ends with:

MISSION COMPLETED AND VERIFIED
CAPABILITY_LOST → CAPABILITY_RESTORED
0 BYTES CHANGED

The part I care about most there is not the green UI.

It is 0 BYTES CHANGED.

The same deployed agent is still there. ToolSuture repaired the compatibility around it.

The harder case was knowing when to stop

Once I had the safe recovery working, I did not want the demo to imply that every API change should be repaired automatically.

That would be reckless.

So I built a second scenario where the change looks superficially manageable but the meaning is different.

The original tool moves a draft into recoverable trash with a 30-day recovery window.

The new provider changes that behavior into irreversible permanent deletion.

At a schema level, those operations can still look related.

Operationally, they are not the same action.

ToolSuture refuses:

REFUSE
CRITICAL
BLOCKED
SAFE_HOLD
0 EXECUTION ATTEMPTS

I actually like this result as much as the successful recovery.

The safe case says:

this changed, but it still means the same thing — act.

The dangerous case says:

this looks related, but it no longer means the same thing — stop.

That is a much more useful definition of autonomy than simply giving an agent permission to do more.

The architecture decision that made the project click

The biggest improvement came when I stopped treating recovery as one big AI step.

ToolSuture separates three jobs.

Semantic reasoning

Gemini 3.6 Flash on Vertex AI interprets whether the old and new tool contracts preserve the meaning required by the original mission.

Execution authority

Gemini does not get unrestricted authority to execute arbitrary generated fixes.

A deterministic policy and validation layer decides whether the proposed migration stays inside the allowed repair envelope.

Verification

The recovery path is not allowed to declare itself successful just because the replay looked convincing.

A separate verifier checks fresh provider evidence tied to that specific replay.

That led to the design principle I kept using throughout the project:

The component that performs recovery does not get to certify that recovery succeeded.

The rest of the stack is intentionally straightforward:

Google Agent Development Kit (ADK) for the frozen deployed agent
Google GenAI SDK
Google Cloud Run for the public application
FastAPI
MCP
Python

I built ToolSuture for the All Things Agentic Hackathon, so I also wanted the Google stack to be doing real work rather than appearing in the architecture diagram as decoration.

Gemini is responsible for semantic reasoning.

ADK is the framework used by the frozen agent.

Cloud Run hosts the live application.

I wanted evidence, not just a nice result screen

One thing I have become increasingly skeptical of in agent demos is the phrase:

“The agent says it succeeded.”

That is not the same as proving the external task succeeded.

So ToolSuture records and verifies evidence from the current replay instead of trusting the agent's own success message.

The current evaluation includes:

3 / 3 repeated verified Cloud recoveries
16 / 16 independent checks on the primary safe replay
5 / 5 blind evaluation scenarios using the frozen recovery engine
0 bytes changed to the deployed agent
0 execution attempts in the dangerous migration

Those numbers are less flashy than adding another feature, but they made me trust the system more.

The goal was never:

“Generate a plausible migration plan.”

It was:

Restore the original capability and prove that it works again.

What I learned

The biggest lesson for me was that AI reasoning is more useful when its authority has clear boundaries.

Gemini is good at interpreting semantic relationships that would be painful to encode as static rules.

But interpreting something, authorizing it, executing it, and verifying it are four different responsibilities.

Separating those responsibilities made ToolSuture much easier to reason about.

I also came away thinking differently about agent reliability.

Before this project, I mostly thought about whether the agent itself could complete a task.

Now I think the better question is:

Can the capability survive changes outside the agent, and can the system prove that it still works afterward?

That is what ToolSuture is testing.

Try ToolSuture

Live demo:

https://toolsuture-fx7bbo3mpq-wl.a.run.app/

Source code:

https://github.com/mneang/toolsuture

Hackathon:

https://allthingsagentichackathon.devpost.com/

APIs change. Your agent shouldn't have to.

False Green: My Incident Agent Said “Healthy” Without Live Evidence

Michael Neang — Mon, 24 Aug 2026 04:08:29 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

The pipeline was healthy.

At least, that was what my incident agent told me.

There was one problem: it could not see the live Fivetran pipeline.

The live check had failed, so the app fell back to cached evidence. That snapshot still said connected and on_schedule.

The final verdict was still:

Healthy.

Nothing crashed.

The request succeeded.

The fallback data looked healthy.

The conclusion was still wrong.

The application had taken the last known state and quietly treated it like the current one.

That was the false green.

Current confidence requires current evidence.

Project Overview

Pipeline Rescue Agent is a Next.js incident-investigation app that combines connector-health and data-freshness signals to decide what still needs investigation.

Gemini runs later in the recovery-planning flow. The false-green verdict occurred in deterministic application logic before the model was involved.

The question at this decision point was simple:

Is this pipeline healthy right now?

I found a case where the application was more confident than its evidence allowed.

Bug Fix or Performance Improvement

When live Fivetran telemetry became unavailable, Pipeline Rescue Agent fell back to cached connector evidence.

I wanted to keep that fallback. The last known connector state can still be useful during an incident.

The failed live path was the trigger condition.

It was not the application defect.

The defect was what happened afterward: cached evidence was still allowed to support a current Healthy verdict.

Before the fix, the decision state looked like this:

evidence.mode = cached_fivetran_evidence
evidence.live = false

fivetran.mcp_ok = false
fivetran.setup_state = connected
fivetran.update_state = on_schedule

pipeline.health_verdict = healthy
false_green.detected = true

Debugging chronology

There are three intentional repository states in this investigation:

State	Purpose
`6194a3b14efd33a0d5f8235f703187005123a0f9`	Historical tagged baseline, before Sentry instrumentation
`b3a45110`	Sentry instrumentation added while the decision bug was still intact
`b05d2cccf93713f6a52a4a4ec6fa6b1600cbec86`	Final fixed state

The sequence was deliberate:

reproduce
→ instrument the still-broken decision
→ inspect
→ diagnose
→ fix
→ verify

Pre-fix Sentry decision span: cached, non-live evidence still produced a Healthy verdict.

Almost every individual status value looked reasonable.

The /api/investigate request itself completed successfully. The fallback returned data. The cached connector status said connected and on_schedule. There were no active warnings or tasks.

The endpoint completed successfully; the semantic failure itself raised no exception.

The contradiction only appeared when evidence provenance and the final decision were inspected together:

cached evidence
+ live = false
+ MCP unavailable
→ Healthy

The cache itself was doing its job.

The health gate was asking the cache to prove something it could not prove.

Cached evidence could answer:

What was last known?

It could not answer:

Is the pipeline healthy right now?

Why this mattered

Healthy was not only a displayed status.

The connector decision feeds the agent's final pipelineStatus, which getLikelyIssue uses when choosing what the investigation should examine next.

When connector health cannot be established:

Needs review
→ likely issue: Connector health

When the connector is considered healthy while destination data is stale:

Healthy + stale data
→ likely issue: Upstream source freshness

A false green did not merely change the displayed status; it could change what the investigation examined next.

I did not need the application to assume Fivetran was broken. I needed it to stop clearing connector health when current connector evidence was unavailable.

Sentry Exposed the Contradiction

I first reproduced the suspicious Healthy result through /api/investigate.

Before fixing it, I added a custom Sentry pipeline.decision span containing the runtime state behind that decision:

evidence.mode
evidence.live
fivetran.mcp_ok
fivetran.setup_state
fivetran.update_state
pipeline.health_verdict
false_green.detected

This was a silent correctness bug.

The request worked. The fallback worked. The values looked plausible. The failure was in the conclusion drawn from them.

Sentry put the healthy-looking status content, its non-live provenance, and the final verdict in the same trace.

That changed the debugging question from:

Why does this endpoint say Healthy?

to:

Why is non-live evidence allowed to support Healthy?

Seer and the root cause

I used Seer to analyze the captured failing trace.

It highlighted evidence currentness as the likely missing decision constraint: healthy-looking cached values were reaching a verdict path that did not enforce live provenance.

Seer RCA: the failing trace pointed to evidence currentness/provenance as the missing decision constraint.

I treated that as a hypothesis and verified it against the source.

I also did not copy the generated suggestion literally.

Pipeline Rescue Agent supports two legitimate live evidence paths:

mcp_live
live

A direct live Fivetran API response can still be current evidence even when the MCP path is unavailable.

So the correct invariant was not:

Healthy requires MCP success

It was:

Healthy requires live evidence

The Missing Invariant

The bug reduced to one safety property:

A Healthy verdict requires live evidence.

Healthy ⇒ evidence.live = true

The failing Sentry trace violated it:

evidence.live = false
pipeline.health_verdict = healthy

The cache could remain; only the decision boundary had to change.

Code

PR: Fix false-green pipeline health verdicts from cached Fivetran evidence

I isolated the health decision in a small helper used by the production route:

export function evaluateFivetranHealth({
  mode,
  setupState,
  updateState,
  hasWarnings,
  hasTasks,
  paused,
}) {
  const hasLiveEvidence = mode === "mcp_live" || mode === "live";

  const isHealthy =
    hasLiveEvidence &&
    setupState === "connected" &&
    updateState === "on_schedule" &&
    !hasWarnings &&
    !hasTasks &&
    paused === false;

  return {
    hasLiveEvidence,
    isHealthy,
  };
}

The important distinction is small:

Evidence	What it may establish
Live	May certify current health
Cached	Historical context only; cannot independently certify current health

Historical evidence can still inform the investigation.

Only current evidence may certify current health.

My Improvements

I checked the surrounding investigation flow for the same provenance assumption. Cached Fivetran evidence no longer appears as a successful current connector check, no longer counts as live evidence, and is no longer described in recovery reasoning as if it represented current health. The production rule now lives in the small pure helper above, which also makes the decision boundary directly testable.

After: Same Non-Live Evidence Class, Safer Decision

The final Sentry trace from commit b05d2cccf93713f6a52a4a4ec6fa6b1600cbec86 shows:

evidence.mode = cached_fivetran_evidence
evidence.live = false

fivetran.mcp_ok = false
fivetran.setup_state = connected
fivetran.update_state = on_schedule

provenance.guard_applied = true
pipeline.health_verdict = needs_review

Final Sentry decision span: the same non-live evidence class now produces Needs review.

The status values still look superficially healthy.

The live telemetry is still unavailable.

The fix did not make unavailable telemetry available. It changed what conclusion the application was allowed to derive from that uncertainty.

cached + non-live
→ Needs review

Historical RED → Final GREEN

I wanted stronger verification than:

The patched application passes a test written after patching it.

So I moved the decisive assertion outside the repository and ran it unchanged against the tagged historical application and the final branch.

The script imports no application decision logic. It intentionally reads only response fields available in both versions:

timeline[].evidence.mode
agentRun.decision.pipelineStatus

It also refuses to count a run if the expected cached-fallback condition was not reproduced.

In simplified form, the external assertion enforced three conditions:

if (mode !== "cached_fivetran_evidence") {
  throw new Error("TEST INVALID: cached fallback was not reproduced");
}

if (verdict === "Healthy") {
  process.exit(1);
}

if (verdict !== "Needs review") {
  throw new Error(`Unexpected verdict: ${verdict}`);
}

I ran that same external assertion against the historical baseline:

Commit:
6194a3b14efd33a0d5f8235f703187005123a0f9

Evidence mode:
cached_fivetran_evidence

Pipeline verdict:
Healthy

Result:
FAIL

Exit code:
1

Then I ran it against the final branch:

Commit:
b05d2cccf93713f6a52a4a4ec6fa6b1600cbec86

Evidence mode:
cached_fivetran_evidence

Pipeline verdict:
Needs review

Result:
PASS

Exit code:
0

External black-box check: historical baseline fails; final branch passes.

This comparison does not claim that every low-level cause of telemetry unavailability was identical between the two executions.

That is not what the assertion tests.

The controlled application condition is:

Fivetran evidence is cached rather than live.

The question is:

Can that evidence still certify current health?

Historical application:

Yes.

Final application:

No.

Decision-Boundary Positive Control

There was one more bad fix I wanted to rule out:

What if Healthy simply became impossible?

The same pure predicate imported by the production route was checked on both sides of the boundary:

Scenario	Expected	Result
`cached_fivetran_evidence` + clean status	`Healthy = false`	PASS
`mcp_live` + clean status	`Healthy = true`	PASS
`live` + clean status	`Healthy = true`	PASS

This is intentionally a decision-boundary check.

It does not claim to contact a live MCP server or the live Fivetran API.

Its purpose is narrower: both supported live evidence modes remain eligible for Healthy, while cached evidence does not.

The non-live application behavior is separately verified through /api/investigate and the external black-box assertion.

Verification

Final branch verification:

npm run test:health-invariant
PASS

PIPELINE_RESCUE_URL=http://localhost:3001 npm run test:false-green
PASS

External black-box check
PASS
exit 0

npm run lint
PASS

npm run build
PASS

The HTTP regression check confirms:

Evidence mode: cached_fivetran_evidence
Live evidence: false
Pipeline verdict: Needs review

PASS: non-live cached evidence cannot produce a Healthy verdict.

Best Use of Sentry

This was exactly where Sentry mattered: /api/investigate completed successfully, so ordinary error monitoring did not expose the semantic failure.

The pipeline.decision span made provenance, liveness, connector state, and final verdict observable together inside that successful request.

Sentry did not merely verify the repair after the fact: I captured the contradiction from the still-buggy release, used that failing trace as runtime context for Seer, and then inspected the same decision again after the fix.

Seer then helped narrow that runtime contradiction to evidence currentness, which I verified against the source before implementing the narrower application invariant.

After the fix, the final trace shows:

evidence.live = false
provenance.guard_applied = true
pipeline.health_verdict = needs_review

Sentry did not replace the debugging.

It exposed the hidden decision state that ordinary success/failure monitoring would not have explained.

Final Result

BEFORE

No live Fivetran telemetry
→ cached healthy-looking evidence
→ Healthy


AFTER

No live Fivetran telemetry
→ cached evidence retained as context
→ live-evidence guard
→ Needs review

The cache can still tell an investigator what was last known.

It just no longer gets to answer:

Is the pipeline healthy right now?

Current confidence requires current evidence.

PR: github.com/mneang/pipeline-rescue-agent/pull/1

Tifo Forge: Turning Football Passion Into a Stadium Tifo

Michael Neang — Mon, 13 Jul 2026 00:35:28 +0000

This is a submission for Weekend Challenge: Passion Edition.

During the World Cup, millions of people can watch the same match.

But every stadium tries to say something different before kickoff.

Sometimes it is belief. Sometimes defiance. Sometimes memory. Sometimes unity.

I follow football closely, and some of the moments I remember most are not goals. They are the few seconds before kickoff when the camera pulls wide and an entire stand reveals one message at once.

That was the idea behind Tifo Forge.

It is an interactive experience that turns a team, a supporter emotion, and a symbol into an animated stadium tifo.

Not another match tracker. Not another football chatbot.

Tifo Forge turns supporter emotion into a stadium moment.

What I Built

Tifo Forge asks the user to make three choices:

A national team
A supporter emotion
A visual symbol

The emotions are simple on purpose:

Believe
Defy
Unite
Remember

The symbols include ideas such as lightning, a phoenix, wings, a heart, and dawn.

Once those choices are made, Gemini creates a structured design plan. The browser then turns that plan into an animated stadium display.

I deliberately avoided uploads, accounts, and long setup screens. I wanted someone to open the page and reach the reveal in under a minute.

Three choices are enough to raise the stand.

The final result can be replayed, reset, or saved as an SVG poster.

Demo

Try Tifo Forge:

https://tifo-forge.vercel.app/

I kept thinking about those few seconds before kickoff when everyone in the stadium knows something is about to happen, but nobody has seen the full picture yet.

That became the interaction:

Choose the team
      ↓
Choose the feeling
      ↓
Choose the symbol
      ↓
Raise the tifo

When the user clicks Raise the Tifo, the stadium darkens.

Rows of cards flip into place. The pattern spreads across the curved stand. The central symbol appears, and the chant locks into position.

The user is not asking for a random poster.

They are deciding what the stand believes, how it moves, and what it raises.

One feeling. One stand. One voice.

Japan · Unite · Dawn — the selected inputs, Gemini direction, and completed stand in one view.

One Real Example: Spain, Defy, Lightning

The easiest way to explain the system is with one real generation.

The user chooses:

Team: Spain
Emotion: Defy
Symbol: Lightning

Gemini returned:

{
  "slogan": "SHOCK THE WORLD",
  "layout": "radiating-burst",
  "animation": "stadium-pulse",
  "energy": 95,
  "designReason": "A radiating burst of electric energy mimics a lightning strike, galvanizing the crowd to defy all doubts and roar as one."
}

Each value changes something visible:

slogan becomes the chant
layout controls the mosaic geometry
animation controls how the reveal moves
energy controls the visual intensity

For this result, radiating-burst maps to a center-weighted SVG card formation, while stadium-pulse staggers the timing across the stand.

Gemini selects from a controlled set of supported layouts and animations, so every plan maps to a renderer path that already exists and has been tested.

The model chooses the direction.

The renderer handles the geometry.

Spain · Defy · Lightning — Gemini selected the message, formation, motion, and intensity; the procedural renderer executed the final stand.

Code

The full source is available here:

https://github.com/mneang/tifo-forge

The repository includes the Gemini API route, structured-output validation, procedural SVG renderer, animation system, accessibility behavior, replay and export controls, and the quota-resilient fallback flow.

How I Built It

How Gemini Works Inside Tifo Forge

I did not want Gemini writing HTML, CSS, or SVG.

That is too unpredictable for an experience where the reveal has to stay clean.

Instead, I wanted Gemini making creative decisions while the application handled everything deterministic.

Gemini connects:

Team identity
+
Supporter emotion
+
Visual symbol

and turns them into:

Message
+
Formation
+
Motion
+
Intensity

The response comes back as constrained JSON.

That output is validated with Zod, normalized, and then passed into the procedural renderer.

Supporter selections
        ↓
Gemini creative direction
        ↓
Structured-output validation
        ↓
Procedural SVG renderer
        ↓
Animated stadium reveal

This split kept the project manageable:

Gemini interprets the inputs
validation keeps the response usable
the renderer controls the final experience

Without Gemini, the project would become a fixed rules engine with much less variation.

Without the renderer, the visual output would be much harder to control.

I kept Gemini's job narrow: turn three choices into a design plan the application could actually use.

The Tifo Direction Framework

I used four dimensions to keep each result focused.

1. Message

Can thousands of supporters read and repeat it quickly?

The chant has to be short, emotional, and suitable for a large banner.

2. Formation

Does the layout communicate the feeling before the explanation is read?

A radiating burst feels different from a split banner or a diagonal rise.

3. Tempo

How should the stand reveal itself?

A united design may build row by row. A defiant design may strike outward or sweep diagonally.

4. Intensity

How much visual energy fits the chosen feeling?

Remember should not move like Defy. Believe should not always feel like Unite.

Having these four dimensions also kept me honest while building. Every layout and animation had to answer one question:

Does this actually communicate the chosen emotion?

Technical Execution

Tifo Forge was built with:

Next.js and TypeScript
Google Gemini API
Zod structured-output validation
Motion for React
Procedural SVG rendering

I added visible keyboard focus, reduced-motion behavior, replay, reset, and SVG download so the experience works beyond one ideal desktop demo.

Each team uses a curated palette inspired by its current football identity, while avoiding historical or political references that could distract from the experience.

I kept the scope narrow on purpose.

The project makes one promise and tries to deliver it well.

I would rather make one interaction feel finished than ship five half-built modes.

Reliability by Design

Tifo Forge is built to stay usable even when the Gemini free-tier quota is temporarily reached.

The system:

tries Gemini first
validates every structured response
caches successful Gemini plans
falls back to a deterministic local design plan when needed
labels the source clearly in the interface

That way, a temporary API limit does not turn into a broken demo.

I also constrained the renderer to a tested set of layouts and animations. Gemini still makes the creative decisions, but every result maps to a rendering path the application can handle cleanly.

The tradeoff is less arbitrary visual freedom in exchange for a more reliable experience.

Prize Categories

Best Use of Google AI

Gemini is the creative-direction layer at the center of Tifo Forge. It translates the selected team, emotion, and symbol into the message, formation, motion, intensity, and design rationale that control the final reveal.

Final Takeaway

A tifo is never just an image.

It is thousands of people agreeing to feel the same thing at the same time.

Tifo Forge gives that feeling a message, a formation, and a moment to rise.

What should 50,000 supporters feel together?

That is the question behind the project.

Independent fan project. Not affiliated with or endorsed by FIFA.

Finishing a Tokyo Metro Data Pipeline: The Join I Refused to Fake

Michael Neang — Sun, 07 Jun 2026 05:56:47 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge.

The most important part of my Tokyo Metro dashboard was not a chart.

It was the join I refused to create.

When I came back to this project, I already had useful pieces: station data, passenger averages, line names, revenue data, Japanese and English labels, and Python scripts that could clean some of it. But the project was stuck in the uncomfortable middle. The CSVs existed. The idea still made sense. Some scripts worked.

But I would not have confidently handed the repo to another person.

Not because the idea is bad, but because finishing the last 20% is not glamorous. It is field names, validation, weird edge cases, documentation, screenshots, and deciding what the data should not claim.

The GitHub Finish-Up-A-Thon gave me a reason to stop leaving it half-finished. GitHub Copilot became useful once I treated it less like a generator and more like a reviewer for the parts I was most likely to rush.

I revived the project into a small transit analytics workflow: Python cleaning scripts, cleaned CSV outputs, SQLite validation, SQL business queries, a documented data model, and a Japanese-first bilingual Tableau dashboard called:

東京メトロ需要・収益分析 / Tokyo Metro Demand & Revenue Analytics

Project links:

Final dashboard: a Japanese-first bilingual view of revenue trends, passenger demand by line, and major station hubs.

I was not trying to present this as an official Tokyo Metro product. I wanted it to become a finished portfolio project that could survive basic questions:

Where did the data go?

Which joins are valid?

What does the dashboard answer?

What are the limitations?

My background is in business systems, reporting, data quality, and operational workflows, so I approached this less like a “make a cool chart” project and more like a small internal analytics deliverable. In that kind of work, a clean visual is not enough. The numbers need a path behind them.

What I Built

The finished version has a simple pipeline:

Processed data

→ cleaned CSVs

→ SQLite database validation

→ SQL business queries

→ Tableau dashboard

→ README and visual documentation

The major outputs are:

cleaned station, line, passenger, and revenue datasets
a SQLite rebuild with row-count validation
SQL queries for passenger demand, station hubs, and revenue trends
an ERD and standalone revenue caveat
a published Japanese-first bilingual Tableau dashboard
a README that explains what the project does and what the data cannot claim

The final dashboard focuses on three questions:

How is system-wide revenue trending by fiscal year and month?
Which lines carry the highest passenger demand?
Which stations stand out as major hubs?

I kept the interface Japanese-first because the subject is Tokyo Metro. English is included for accessibility, but Japanese leads the dashboard.

I have visited Tokyo three times, and that made me more careful about the interface. I did not want the Japanese labels to feel decorative. I wanted them to lead the dashboard because that is the natural context of the data.

I also kept the filters limited:

会計年度 / Fiscal Year for revenue views
路線 / Line for passenger views

I intentionally avoided adding every possible slicer. A dashboard does not become better just because it has more controls.

Demo

The final dashboard is a compact view of demand and revenue.

It is designed around a smaller set of practical questions:

Are revenue trends recovering or weakening?
Which lines carry the most passenger demand?
Which stations act as major hubs?
What should the viewer not assume from this data?

The dashboard includes a note that revenue is system-wide, while passenger data is station/line-based. That prevents the viewer from assuming the revenue data can be filtered by line or station.

I skipped a map on purpose. The cleaned station data did not include reliable latitude and longitude fields. A map would have looked nice, but it would not have been honest.

The Comeback Story

Before the finish-up work, this project had potential but no real finish line.

The old version had a minimal README, cleaning scripts that needed polish, inconsistent field naming around revenue and fiscal month fields, no strong SQLite validation story, no clear data model explanation, and no published dashboard.

Before: the project had the idea, but not enough documentation or finish.

The biggest fix was not visual.

The biggest fix was deciding what had to be true before the dashboard deserved to exist.

For this project, I treated “finished” as a checklist:

Can the cleaned files be regenerated?
Can the database be rebuilt?
Can the row counts be validated?
Do the SQL queries answer real questions?
Are the data relationships honest?
Can someone open the dashboard without me explaining it live?

Instead of jumping straight back into Tableau, I went through the cleaning scripts, the field names, the SQLite import, and the data model.

One issue that forced the project to grow up was the station data. The Marunouchi Branch Line created a duplicate Station_ID problem during SQLite loading. That was annoying at the time, but it was also useful. SQLite caught something Tableau might have let me hide visually.

So I fixed the cleaning logic instead of working around the problem.

After that cleanup, the database rebuild became a real proof point. The final import step loads:

14 rows into Lines
291 rows into Stations
119 rows into Passengers
48 rows into Revenue

That terminal output became one of the most important screenshots in the project. It showed that the pipeline could rebuild from cleaned files instead of depending on a manual Tableau-only workflow.

The SQLite rebuild became the project’s validation checkpoint.

The Data Modeling Decision That Mattered

The most important modeling decision was deciding what not to join.

The passenger side of the project has a natural path:

Lines → Stations → Passengers

That lets me analyze passenger demand by line and by station.

Revenue was different.

The revenue table had fiscal year, fiscal month, commuter revenue, non-commuter revenue, total revenue, and YoY percentage fields. It did not have Line_ID or Station_ID.

So I kept revenue standalone.

That is not as exciting as adding another relationship in a diagram, but it is more honest. If I forced revenue into the station or line model, the dashboard would look more connected while becoming less trustworthy.

I have seen enough reporting work to know that the dangerous chart is not always the broken one. Sometimes it is the clean chart built on a relationship that should not exist.

That became the core lesson of this project:

Do not join data just because the dashboard would look more impressive.

Revenue remains standalone because the source does not include line or station keys.

My Experience with GitHub Copilot

The most useful Copilot work happened after I already had something running.

I did not ask it to build the whole project. I used it more like a second reviewer for the parts that are easy to rush when you are trying to finish:

Are the backend scripts readable?
Are there obvious validation gaps?
Are the comments and print messages clear?
Are the SQL queries understandable to someone reviewing the project?
Am I about to make a risky change for no real benefit?

The best prompts were specific. For example, I asked Copilot to review import_data_to_sqlite.py, clean_station_data.py, and create_line_data.py for clarity, validation, and maintainability while preserving the output schema.

That last part mattered. When a project is close to finished, a large refactor can be a trap. I needed safe improvements, not a new project.

Here is the kind of Copilot help that was actually useful: not “build the project for me,” but “review these scripts and point out what would make them safer to rerun.”

Copilot reviewing the backend scripts for validation and maintainability. I used it as a reviewer, not as an autopilot.

One concrete example was the SQLite import workflow. I had a script that could load the cleaned files, but Copilot’s review pushed me to think more like a maintainer: check expected inputs, preserve the schema, keep the output predictable, and make the final row counts visible.

The most useful outcome was not a giant rewrite. It was a tighter import workflow: expected files checked, table schemas respected, and row counts printed at the end so the pipeline had a visible pass/fail moment.

I still had to test the result myself. Copilot did not replace that. But the review helped turn the script from “works on my machine” into something I could actually show in the submission.

I also did not accept every suggestion. The useful ones were the ones that made the pipeline easier to verify without changing the data model. Suggestions that felt like unnecessary refactoring or scope creep stayed out.

The pattern that worked best was boring, but useful:

Ask for review
→ keep the safe suggestions
→ reject the risky ones
→ rerun the pipeline
→ verify the output

That is probably how I will use Copilot more often: not as a replacement for judgment, but as pressure against sloppy finish-up work.

What the SQL Layer Added

Once the database loaded, I used SQL as a sanity check before going back to Tableau.

The queries were not meant to be complicated. They were meant to answer questions a transit analyst or business reviewer would understand:

Which lines carry the most passenger demand?
Which stations act as major hubs?
How has revenue changed by fiscal year?
How do commuter and non-commuter revenue streams compare?

That helped me avoid treating Tableau as the only proof. The dashboard became the final interface, not the only place where the logic existed.

This mattered because a dashboard can hide a lot. SQL forced me to look at the grain of the data before designing around it.

SQL checks helped validate business questions before building the Tableau view.

Before and After

Here is the short version of the comeback:

Area	Before	After
Documentation	Minimal README	Project page with links, screenshots, and caveats
Data cleaning	Scripts existed but needed cleanup	Normalized cleaned datasets
Database	No strong validation checkpoint	SQLite rebuild with row-count validation
SQL	Exploratory or missing	Business-focused queries
Data model	Relationships not clearly explained	ERD plus standalone revenue note
Dashboard	Not finished	Published bilingual Tableau dashboard
Copilot	Not part of the workflow	Used for review, validation, and polish

That before-and-after is what led me to a checklist I will reuse.

My Finish-Up Checklist for Data Projects

Before calling a data project done, I want to be able to answer:

Can I regenerate the cleaned data?
Can I rebuild the database or analysis layer?
Can I validate row counts?
Can I explain every relationship in the model?
Can I explain what is intentionally not related?
Can SQL answer the core business questions?
Can the dashboard be used without me narrating it?
Are the caveats visible enough that someone will not overread the data?

What I Would Improve Next

If I had more time, I would add:

automated tests for the cleaning scripts
a GitHub Actions check that rebuilds the SQLite database
clearer source-data documentation
accurate latitude and longitude data before attempting a map

I skipped a map on purpose. Without reliable latitude and longitude data, it would have made the project look better while making it less accurate.

Final Takeaway

For this repo, finishing meant cleaning the data, validating the load, documenting the model, refusing a bad join, and building a dashboard someone else could actually use.

Copilot helped with the review and polish, but the main value came from deciding what “done” should mean.

That is what changed this from an abandoned side project into a shareable analytics workflow.

Stop Asking Gemma 4 to Just Summarize

Michael Neang — Sun, 24 May 2026 01:34:58 +0000

This is a submission for the Gemma 4 Challenge: Write About Gemma 4

A small test of using open models to expose uncertainty, not hide it.

Most AI demos start with clean prompts.

Real work usually starts with messy notes.

A stakeholder says the number looks wrong. Someone else says a field changed. Another person says the source file was cleaned. The dashboard owner is out. A manager still needs an update before a leadership meeting.

That is the kind of situation I wanted to test with Gemma 4.

I work around business systems, reporting, data quality, and process handoffs, so this felt familiar. In real reporting work, the dangerous moment is not always when the dashboard breaks. It is when everyone wants an answer before anyone has checked the source.

So I tested one practical question:

Can Gemma 4 do something more useful than summarize messy notes?

More specifically:

Can it separate the mess into what is known, what is assumed, what is risky, and what still needs checking?

That is the difference I cared about.

A summary compresses messy information. A review packet separates it into facts, assumptions, risks, and next checks.

The test setup

I kept the test small on purpose.

I used Google AI Studio with Gemma 4 26B A4B IT. I used the same messy notes twice, with the same model settings: temperature 0.25, thinking level set to High, no tools, and no system instructions.

I left system instructions blank because I wanted the prompt itself to carry the behavior.

This was not a model comparison. It was a prompt-pattern comparison.

The only thing I changed was the prompt.

The scenario was synthetic, but realistic: a weekly operations report is due Monday morning, the totals look lower than expected, a field name changed last week, duplicate rows may have been removed, and the dashboard owner is out.

No private data. No company data. Just the kind of messy report situation that creates pressure before a meeting.

Here were the notes, shortened for the test:

A weekly operations report is due Monday morning.

The report usually refreshes Sunday night.

A field name changed last week.

A stakeholder says totals look lower than usual.

Duplicate rows may have been removed from the source file.

The dashboard owner is out.

Nobody knows yet whether the issue is source data, filter logic, or a definition change.

Prompt 1: ask for a normal summary

First, I asked:

Summarize these notes for the manager and explain what is going on.

The result was not bad.

Baseline run: same Gemma 4 model, same notes, no system instructions.

Gemma 4 gave me a manager-ready update and a plain-English explanation of why the team should avoid giving final numbers yet. One useful line was:

“Investigation in progress regarding a discrepancy in the weekly totals.”

I could imagine sending a version of that in Slack.

But the summary also showed the weakness of summarization. It used phrases like “red alert,” “flying blind,” and “the numbers look wrong.”

Those phrases made the situation easier to understand, but they also added more certainty and drama than the original notes supported.

The raw notes did not prove the report was wrong. They only said the totals looked lower than usual.

That matters.

A summary can make messy information easier to read while quietly making the situation feel more settled than it actually is.

Prompt 2: ask for a review packet

So I reran the same notes with one change: instead of asking for a summary, I asked for a review packet.

You are an analyst preparing a review packet.

Using only the notes below, return:
1. One-paragraph summary
2. Confirmed facts
3. Assumptions
4. Unverified claims
5. Risks
6. Questions for a human reviewer
7. Suggested next actions
8. What not to conclude yet
9. Final checklist

Rules:
- Do not invent facts.
- Separate facts from assumptions.
- Keep it calm, practical, and concise.
- Help a human decide what to verify next; do not make the final decision.

The output was less polished, but more useful for the decision in front of the team.

It separated confirmed facts from assumptions and unverified claims. For example, it treated “totals look lower than usual” as an unverified claim because that came from a stakeholder report, not from a completed data check.

It also kept the biggest unknown visible:

“The root cause is currently unknown.”

That was the most important part of the output.

In a real reporting issue, people often want to jump straight to the cause: the field change broke it, the source file changed it, the filter logic is wrong.

But in this scenario, none of that had been verified yet.

The strongest section was “What not to conclude yet”:

Do not conclude that the data is incorrect.
Do not conclude that the field name change or duplicate removal caused the discrepancy.
Do not conclude whether the issue is source data, filter logic, or a definition change.

That section changed the output from a status update into a review tool.

Review-packet run: the useful shift was separating facts, assumptions, risks, and what not to conclude yet.

What changed

The better output was not better because it sounded smarter.

It was better because it gave the team a safer shape for the next step.

The summary was better for status communication. The review packet was better for deciding what still needed verification.

The caution: this still does not verify anything

This is the boundary I would not cross.

Gemma 4 did not inspect the report. It did not open the source file. It did not check the dashboard logic. It did not know whether duplicate removal was correct or whether the field name change affected a calculation.

It organized the review path.

That is useful, but it is not the same as verification.

In a real report issue, I would still check the source rows, field mapping, report filters, refresh timing, and metric definition before saying anything final. The review packet does not remove that work. It makes sure I do not skip it.

For messy systems work, I would use this kind of output before the investigation, not after it. It is a way to prepare the human reviewer, not replace them.

The model can turn scattered notes into a checklist for the person doing the investigation.

It cannot do the investigation unless it has access to the actual systems, data, definitions, and business context.

The Review Packet Framework

If someone only copied one thing from this post, I would want it to be this prompt shape.

When the input is messy, uncertain, or time-sensitive, ask the model for:

Summary
Confirmed facts
Assumptions
Unverified claims
Risks
Questions for a human reviewer
Suggested next actions
What not to conclude yet
Final checklist

The most useful parts are not always the summary or the checklist.

For me, the important sections are:

assumptions
unverified claims
risks
what not to conclude yet

Those sections force the model to keep uncertainty visible instead of hiding it inside a clean paragraph.

That is what made the review packet more useful than the summary.

Why I used Gemma 4 this way

I used Gemma 4 this way because messy notes are a real workload.

Reports, support handoffs, incident updates, and project notes rarely arrive in perfect form. The useful question is not only whether a model can write about them. It is whether it can preserve the uncertainty inside them.

That fits the part of Gemma 4 I care about most: not just text generation, but reasoning over messy context and producing something structured enough for a human to use.

For this test, I used the 26B A4B instruction model because I cared more about the reasoning structure than running the smallest possible model. If I were building a lightweight offline helper, I would test a smaller Gemma 4 model next.

Final takeaway

I would still ask Gemma 4 for summaries.

But after this test, I would be more careful about when a summary is enough.

If the situation is messy, time-sensitive, or full of unverified claims, I would rather ask for a review packet.

The useful output is not always the cleanest paragraph. Sometimes it is the output that says:

here is what we know
here is what we are assuming
here is what could go wrong
here is what not to conclude yet

That is the pattern I would reuse.

Gemma 4 did not remove the mess.

It made the mess reviewable.

When the Dashboard Lies: The Google I/O 2026 Agent Test

Michael Neang — Sat, 23 May 2026 21:54:22 +0000

This is a submission for the Google I/O Writing Challenge

It is Monday morning. A leadership meeting starts in an hour. The sales dashboard is open, the numbers look normal, and nobody is seeing a big red error message.

Then someone says the worst possible sentence:

“I don’t think this number is right.”

That is when a dashboard stops being a dashboard and becomes an investigation.

Maybe the refresh timestamp looks fine, but the source data is behind. Maybe the source system has the new records, but the report is filtering them out. Maybe the pipeline technically completed, but skipped something important. Or maybe the number is correct and the business definition changed without everyone realizing it.

That is the kind of problem I thought about during Google I/O 2026.

Google I/O had plenty of bigger moments: new Gemini models, Antigravity, managed agents, AI Studio updates, Firebase improvements, and more ways to build with agents. But the part that stayed with me was not just that agents could do more. It was that Google kept showing the pieces around the agent: tools, sandboxed execution, deployment paths, realtime data, and approval moments.

That matters for business systems.

An agent is not useful because it sounds smart. It is useful if the surrounding workflow helps it check, explain, and stop at the right time.

For me, the test is simple:

Can an agent help investigate a broken dashboard before people trust the wrong answer?

My lens is business systems

My lens is not pure software engineering. I work around business systems: reporting, Salesforce-style processes, data quality, workflow rules, and the awkward handoff between “the system says this” and “the business expected that.”

So when I watch agent demos, I do not only ask:

“Can this write code?”

I ask:

“Could this help figure out why a number is wrong without making the situation worse?”

In reporting work, I have learned to be careful with the phrase “the number is wrong.” Sometimes it means the number is stale. Sometimes it means the filter is wrong. Sometimes it means the user expected a different definition. Sometimes the data is correct, but the timing is not.

Those are different problems. Treating them like one problem wastes time.

A green checkmark on a refresh history page does not always mean the business problem is solved. A dashboard can be “working” and still be misleading.

That is why a dashboard incident is a good test for AI agents. It forces them to handle the parts of work that demos usually skip: stale data, unclear definitions, permissions, uncertainty, and stakeholder communication.

A small example: the $1.2M problem

Imagine a sales dashboard says this month’s booked revenue is $1.2M.

Sales says three new closed-won opportunities came in this morning, so the number should be higher. The dashboard refresh history says the report ran at 8:10 AM. The source system shows the new opportunities were updated at 8:26 AM. The pipeline status says the latest run completed, but with warnings.

Nothing is obviously on fire.

The dashboard loads.

The refresh did happen.

The source system has records.

The meeting still starts in an hour.

This is exactly where vague confidence is dangerous. You do not need someone to say, “Looks fine.” You need someone to narrow the problem.

Is the dashboard stale? Did the source update after the refresh? Did the pipeline skip some records? Is the report filtering out the new opportunities? Should leadership use the current number or wait for an updated one?

That is the broken dashboard test.

The manual version

In real life, these checks rarely happen in a perfect order. You bounce around. You open the dashboard, then the source system, then a refresh history page, then maybe a spreadsheet someone sent last week.

Half the work is technical. The other half is figuring out what people actually mean when they say “wrong.”

A basic dashboard investigation might look like this:

Step	Manual analyst check
1	Check the dashboard refresh timestamp
2	Check whether the source system has newer records
3	Check if the pipeline, export, or sync completed
4	Compare row counts, timestamps, or sample records
5	Look for filters, joins, or definitions that could explain the gap
6	Identify which reports, teams, or decisions may be affected
7	Write a plain-English update for stakeholders

The hard part is switching between tools and contexts while people are waiting. You are trying to separate facts from guesses. You are also trying not to create more panic than necessary.

That is where the Google I/O agent story became useful to me.

The agent version should be boring on purpose

The part of Google I/O 2026 that clicked for me was the move away from “ask a model a question” toward “give an agent a job, tools, and boundaries.”

A model can help explain what a stale dashboard might mean. An agent, designed carefully, could help check the refresh time, inspect a pipeline status, compare a few sample records, and produce a short recovery note for the humans involved.

But the agent version should not be:

“Let the AI fix it.”

That is how you get a bigger problem.

The useful version is more controlled: let the agent organize the investigation, gather evidence, and prepare a recommendation. Then a person decides what to do.

For a dashboard incident, I would want an agent to summarize the issue, identify the systems involved, gather freshness evidence, compare source records against dashboard output, estimate the blast radius, draft a recovery brief, and ask for approval before any risky action.

That last point is not decoration. It is the line between useful automation and reckless automation.

If an agent finds a failed refresh, it can recommend a rerun. If it sees a mismatch, it can flag the likely cause. If it drafts a message, great. But changing production data, editing report logic, disabling a process, or triggering a major workflow should require a human decision.

The goal is faster evidence, not blind autonomy.

Why the Firebase demo mattered to me

One I/O moment that fit this idea surprisingly well was a Firebase SQL Connect realtime demo. The demo itself was playful, but the pattern was familiar: data changed, the app did not immediately show the change, and then realtime sync improved how updates reached the user.

That is basically the dashboard problem in miniature.

Most business users will not describe the issue as a sync problem, a refresh issue, or a data modeling mismatch. They will just say:

“This looks wrong.”

A good agent workflow should help translate that vague sentence into checks that can actually be tested:

When did the dashboard last refresh?
Did the source system receive newer records?
Did the pipeline run fully or only partially?
Are the missing records actually missing, or filtered out?
Who needs to be warned before the meeting?

The value is in turning a vague complaint into checks someone can review.

The recovery brief matters too

The investigation is only half the job; the other half is explaining it without dumping technical noise on people who just need to know whether they can trust the number.

A useful recovery brief should explain what happened, what is confirmed, what is still uncertain, who may be affected, what action is recommended, and when the next update will come.

That sounds simple, but under pressure it is easy to write too much, too little, or the wrong thing entirely.

This is an underrated agent use case. If the agent can gather evidence and draft a calm first version, the analyst can spend more time judging the situation instead of starting from a blank message.

It gives a person something to review.

My caution: investigation and action are different jobs

This is where I get cautious.

A dashboard investigation agent should not have the same permissions as an admin. It should not be able to quietly rewrite report logic, change production data, or trigger a workflow just because it found something suspicious.

Investigation and action are different jobs.

I do not want an agent with admin-level access just because it makes the demo smoother. Convenience is not a permission model.

For this kind of workflow, I would rather start with a read-only agent that can collect evidence, summarize findings, and recommend next steps. If a write action is needed, make the approval explicit.

Read-only first is not a limitation. It is how trust gets built.

Before putting an agent anywhere near a business systems workflow, I would ask these questions first:

Question	Why it matters
Is the workflow repeatable?	Agents work better when the process has structure
Are the systems clearly named?	Vague tools create vague investigations
Can the evidence be verified?	Confidence is not the same as proof
Are permissions scoped?	The agent should not reach everything
Are write actions approval-gated?	Investigation and action need different levels of trust
Is there an audit trail?	People need to understand what happened later
Can a non-technical stakeholder understand the output?	Raw logs are not a recovery update
Is there an escalation path?	Some problems should leave the agent’s hands

The worst version of this agent would be one that confidently guesses. The best version would be one that carefully narrows the search.

Final takeaway

My biggest Google I/O 2026 takeaway is not “agents are powerful.” We already know that.

The harder question is whether they can be useful when the situation is messy, time-sensitive, and full of half-truths.

For me, the test is simple:

Can the agent help move from panic to evidence?

If a dashboard lies, I do not need an agent that sounds confident. I need one that checks the right places, shows what it found, explains what is still uncertain, and stops before doing something risky.

That is the agent I would trust: not the one that replaces judgment, but the one that helps people reach evidence before decisions get made.

Everyone Wants AI Agents. Fewer Teams Are Ready for the Messy Business Context Behind Them

Michael Neang — Wed, 29 Apr 2026 02:56:02 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

I work as a Business Systems Data Analyst, mostly around Salesforce administration, Power BI reporting, and business process support. So when I watched the Google Cloud NEXT ’26 keynotes, the part that stood out to me was not only the models, infrastructure, or demos.

It was the operational reality behind them.

I am not a cloud architect, but I work close enough to Salesforce records, reports, and business processes to know that clean demos are different from real operations.

One line from the Opening Keynote caught my attention:

“You have moved beyond the pilot. The experimenting phase is behind us.”

That sentence made the keynote feel different. It was not just about proving AI can work anymore. It was about what happens when AI has to work inside real companies, with real data, real permissions, real users, and real consequences.

That is where the agentic enterprise actually clicked for me.

Because the hard part is rarely the perfect demo. The hard part is the messy workflow after the demo.

The real shift is not chat. It is action.

For a long time, business technology has helped people understand what already happened.

A dashboard shows performance. A report shows trends. A validation rule blocks bad data. A workflow moves a process forward.

Agents introduce a different question:

What if the system does not only show information, but helps someone decide what to do next?

A dashboard might show that inventory is stale, a deal is stuck, or a support queue is growing. An agent could help investigate why, check related records, suggest the next action, draft a response, create a task, or hand work off to another system.

That is exciting, but it also raises the standard.

If an agent is going to assist with real work, it cannot behave like a random chatbot. It needs to understand the workflow, the data, the rules, and the boundaries of what it is allowed to do.

I do not see the best use of agents as replacing people outright. I see them more as operational assistants that need onboarding, boundaries, and review.

A new employee does not get access to everything on day one. They need context. They need process knowledge. They need someone to explain what “done” actually means.

Agents are not that different.

Context is the difference between useful and dangerous

The strongest line from the keynote, for me, was this:

“Reasoning without context is just a guess.”

That is the line I kept coming back to.

An AI model can be powerful, but if it does not understand the business meaning behind the data, it can still make the wrong recommendation with confidence.

In a company, words like revenue, risk, status, approval, customer, inventory, or complete are not universal. They depend on systems, departments, rules, and history.

“Risk” could mean credit risk, operational risk, compliance risk, fraud risk, or customer churn risk.

“Revenue” could mean booked revenue, net revenue, recognized revenue, projected revenue, or something else depending on the report.

Even a simple status field can carry a lot of business meaning behind it.

That is why the Agentic Data Cloud and Knowledge Catalog parts of the keynote stood out to me. The interesting part was not only that data can be stored or searched. It was the idea that agents need trusted business context to act correctly.

Without that context, an agent can sound impressive and still be wrong.

My biggest takeaway from NEXT ’26 is this:

The future of agents is not only about smarter models. It is about better context.

Good agent systems look more like teams

The Developer Keynote made the agent platform feel practical.

The marathon planning demo used multiple agents: a Planner Agent, an Evaluator Subagent, and a Simulator Agent. That stood out because a useful agent system is not necessarily one giant chatbot trying to do everything.

It is more like a team.

One agent creates the plan. Another evaluates it. Another simulates what could happen.

That model makes sense because real business workflows already operate like this. Work moves through roles, checks, approvals, handoffs, and reviews. One person or one system usually does not own everything from start to finish.

The demo also reminded me that agents are still software.

They may feel more flexible than traditional applications, but they still need testing, monitoring, permissions, debugging, and maintenance. If anything, they may need even more discipline because they can reason, call tools, and take action in less predictable ways.

That is not a reason to avoid agents. It is a reason to build them seriously.

Action needs guardrails

The most exciting shift is that agents are moving from answering questions to taking action.

But action increases risk.

An agent that only answers questions has limited impact. An agent that can take action has real value. An agent that can take action without guardrails can create real problems.

That is why least privilege stood out to me. Agents should access only what they need, only when they need it. An agent should not automatically have access to every system or every data point just because access might be useful.

If an agent can update financial data, send customer communication, change a workflow, trigger a deployment, or access sensitive records, then the organization needs to know exactly what that agent is allowed to do.

It also needs to be traceable.

Who or what took the action? What data did it use? What tool did it call? Was a human involved? Can the decision be reviewed later?

This is where governance becomes more than a compliance checkbox. It becomes part of whether people trust the system enough to use it.

My checklist before trusting an enterprise agent

Before trusting an enterprise agent in a real workflow, I would ask:

What data can it access?
What action can it take?
What business rule is it following?
Who reviews the output?
Can we trace what it did?
What happens when it is wrong?

A good enterprise agent should not only be impressive. It should be understandable, useful, controlled, and accountable.

Final takeaway

Google Cloud NEXT ’26 made the agentic enterprise feel more real to me.

Not because agents can answer questions. We already know AI can answer questions.

It felt real because the conversation moved toward the harder parts: production workflows, trusted context, governance, evaluation, observability, security, and action with guardrails.

The companies that win with agents will not only be the ones with the smartest models. They will be the ones with clean data, clear processes, strong governance, and people who understand the business context.

To me, that is the real message of the agentic enterprise: not replacing work, but helping people act with better context, better systems, and more confidence.

IntelSync: Multi-Agent Market Intelligence with Google ADK & Google Cloud

Michael Neang — Mon, 23 Jun 2025 16:56:20 +0000

IntelSync: Building Multi-Agent AI Systems with Google ADK & Google Cloud

Created for the purposes of entering the Google Cloud Agent Development Kit Hackathon. #adkhackathon

🚀 Project Overview

With AI agents on the rise, the true potential emerges when they collaborate. IntelSync leverages Google’s Agent Development Kit (ADK) to orchestrate multiple autonomous agents, streamlining complex business intelligence tasks through real-time news scraping, seamless integration with BigQuery, and instant, actionable insights via Google Cloud NLP APIs.

🔧 Technologies & Tools

Google Cloud BigQuery: For scalable data warehousing.
Google Cloud Natural Language API: Real-time sentiment analysis and content insights.
Agent Development Kit (ADK): Robust orchestration and execution of multi-agent workflows.
Streamlit: Intuitive real-time dashboarding and visualization.

🛠 How I Built It

Agent Orchestration with ADK:

Used Google's ADK to orchestrate distinct agents (web scraping, data loading, NLP insights) working autonomously yet cohesively.
Google Cloud Integrations:

Integrated seamlessly with BigQuery and Natural Language API, enhancing the agent workflow's scalability and intelligence.
Real-time Visualization:

Leveraged Streamlit for an intuitive and interactive dashboard providing insights at a glance.

🏗 Technology Architecture

🧠 Findings & Impact

Successfully automated complex multi-step data workflows.
Demonstrated practical use cases for multi-agent collaboration.
Explored real-world applications for autonomous insights generation and data-driven decision-making.

🎓 Learnings

Effective orchestration of AI agents significantly enhances business intelligence processes.
Google's ADK simplifies multi-agent management, making complex AI workflows accessible and powerful.

🔗 Project Links

🌟 Acknowledgements

Thanks to Google Cloud and the ADK team for providing such an exciting platform and opportunity to innovate with multi-agent systems.

#adkhackathon #GoogleCloud #ADK #AI #DataAnalytics