DEV Community: Michael Neang

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