From an AI That Researches to a Business System That Can Decide and Act—the Business Builders Track

The “exceptionally capable new hire” we welcomed on Day 1 was good at reading documents, searching, and summarizing key points. In the Business Builders Track on Day 2, we assign that new hire a more challenging task.

Research the market and internal data, compare acquisition candidates, prepare a report, and proceed with the next business process once it has been approved.

In this article, a Business Agent is an Agent that does more than answer questions: it supports document research, data analysis, waiting for approval, and post-approval business processing.

At first glance, this may look like nothing more than a combination of search, summarization, and spreadsheets. However, the work includes processes with very different characteristics.

• Collect evidence from the Web and internal documents
• Verify that the evidence refers to the same company, period, and metric
• Handle missing values and outliers, then perform calculations
• Interpret the results while separating facts from speculation
• Organize the results into a form that people can review
• Proceed with external actions only for approved content
• Explain afterward who decided what and on what basis

If all of this is forced into a single “smart chat,” the writing may be fluent, but it can still produce mismatched citations, outdated documents, invisible permission leaks, speculation presented as fact, content substitutions after approval, and duplicate executions.

This article examines public Web search, connections to internal data, image and video analysis, source-grounded answers, Python calculations, human approval, and post-approval processing not as a collection of unrelated conveniences, but as a single business system: “evidence → decision → approval → execution → audit trail.” Each product name is introduced in the section that explains its role.

A Map of This Article

Let us begin with the overall picture.

The following table can be read from top to bottom as the chronological sequence of an acquisition research case. For now, it is enough to understand that each stage has different failure modes. We will build the safeguards one stage at a time in the main text.

The central proposition of this article is as follows.

The quality of a Business Agent is determined not by the fluency of its final text, but by whether claims can be traced back to evidence, the assumptions behind decisions can be explained, approvals can be linked to execution, and the results can be audited.

We Will Follow a Single Case Throughout

To prevent every change in functionality from looking like a separate demo, we will keep the narrative centered on one case. We will introduce Mr. Sato as a fictional business leader and Company A as a fictional acquisition candidate. Mr. Sato asks a “research Agent,” which investigates multiple sources in sequence, to conduct preliminary research on Company A. In this article, we call this research role the Research Agent.

The Research Agent examines the public Web and internal documents, calculates financial data, reviews video, and compares candidates. However, it cannot contact candidate companies or update internal systems until approval is granted.

Mr. Sato and Company A are fictional constructs used to explain multiple capabilities as a single business process. Screens and results identified in the text as coming “from the exercise” are items confirmed during the hands-on session. The fictional decision-making scenario and the factual exercise results are described separately to avoid conflating them.

We divide this case into five scenes.

1. What was collected as evidence
2. What was judged from that evidence as fact, assumption, or prediction
3. What Mr. Sato reviewed and which execution plan he approved
4. Whether only the approved content was executed exactly once
5. Whether the decision and execution can later be reproduced from the same audit trail

Each capability—search, source consultation, calculation, approval, and business processing—is a tool responsible for one part of these five scenes. Rather than memorizing product names, focus on which handoff each tool is designed to make reliable.

First, Translate the Terminology into Everyday Language

English terms continue to appear alongside the explanations below so that readers can return to official documentation and implementation resources. When interpreting their meaning, it is fine to begin with the everyday-language analogy in the rightmost column.

The article proceeds in three phases. Phase 1, Chapters 1–4, establishes the foundations for evidence, permissions, video, and approval boundaries. Phase 2, Chapters 5–8, focuses on analysis that gives people the information they need to decide. Phase 3, Chapters 9–16, connects evidence to execution and covers ongoing operations. At the end of each phase, we review what has been resolved and what remains.

1. The First Task: Turn Web Search into “Evidence Collection”

Gemini Enterprise, used in the exercise, is an environment in which people in an organization can use AI Agents to research public information and authorized business data. Within it, the mechanism that connects answers to reference information from Web searches is called Web Grounding. We will begin with this process of “searching and attaching sources.”

1.1 Having Search Results Is Not the Same as Substantiating a Claim

Suppose the new hire reports, “Company A’s revenue has grown by 20%.” Even if the report includes a link, the claim is not necessarily correct.

• The link may refer to Company A’s parent company rather than Company A
• The metric may be gross merchandise value rather than revenue
• The period may be quarterly rather than annual
• The 20% may be relative to a plan rather than year over year
• The currency or accounting standard may be different
• The article may have been corrected after publication

What is needed is not a list of reference links at the end of an answer, but a mapping between each claim and the specific passage that supports it.

In this diagram, we trace a claim back to the relevant passage, document, publisher, and point in time. We then verify the company name, period, metric, and unit. If any of these differ, the link does not support the claim even though it exists.

1.2 Do Not Treat Text That Is Still Being Generated as a Final Answer

In an answer that uses Web Grounding, the terms used for the search, retrieved sources, and text being generated appear progressively. In the exercise, we were also able to review answers involving search and their references.

For users, streaming reduces perceived waiting time. However, it is dangerous for downstream processes to treat partially displayed text as immediately finalized information. Citations may be added later, the text may be revised, and the conclusion may change.

At a minimum, the system should therefore distinguish the following states.

Drafting → Verifying evidence → Finalized → Human-reviewed → Actionable

Text appearing on the screen is not treated as equivalent to information being finalized for business purposes.

1.3 Grounding Metadata Is Not a Certificate of Truth

Grounding with Google Search and Grounding Metadata make it possible to retrieve the terms used for the search, text fragments that supported the answer, references, document names, and publisher domains.

This substantially improves traceability. However, metadata indicates which information was consulted; it is not a certificate that automatically establishes the truth of a claim.

In production, it is useful to maintain a claim ledger for each claim.

A claim ledger is a “claim register” that maps each claim in a report to its evidence, one row at a time.

The following JSON illustrates how a sentence in a report can be connected to its evidence and verification status. You do not need to read the code. The important point is that the text, citation, target company, period, metric, and verification result are stored as a single record.

{
  "claim": "The target company's annual revenue increased 20% year over year",
  "claim_type": "reported_fact",
  "entity": "target-company",
  "period": "FY2025",
  "metric": "revenue",
  "unit": "percent_yoy",
  "source_uri": "https://example.invalid/report",
  "supporting_passage_hash": "sha256:...",
  "published_at": "2026-02-10",
  "retrieved_at": "2026-09-04T04:00:00Z",
  "verification": "entity-period-metric-unit matched"
}

With this format, even if a document is updated later, it remains possible to trace which passage served as the basis for the decision at that time. A hash here is a digital fingerprint generated from content. Because the hash changes when the content changes, it can be used to confirm whether the version is the same. When storing records, limit them to the necessary identifiers and hashes rather than the full text, in accordance with copyright, confidentiality, and retention policies.

1.4 Choose the Type of Search Based on Requirements

Compared with standard Google Search Grounding, Web Grounding for Enterprise differs in its handling of regulatory requirements and input data, as well as in how its search scope is updated.

Do not select an option solely because it has “better search accuracy.” Treat the following as requirements.

• Handling of input data
• Search scope and update frequency
• Regional, language, and regulatory requirements
• Metadata required for citations
• Audit and retention requirements
• Conditions for combining internal information with the public Web

Review so far

We have moved beyond merely producing text about Company A with links. For each claim, we now verify the relevant passage, target company, period, metric, and unit, and preserve the retrieval time. Grounding metadata is an entry point for traceability, not proof of correctness itself.

What remains: The public Web alone does not provide enough internal conditions or detailed data for an acquisition decision. Next, we will connect to internal data, but we must distinguish what can be found from what may legitimately be viewed.

2. Connecting Internal Data: Separate What Can Be Found from What May Be Viewed

2.1 The List of Available Agents in Agent Gallery Is Not Proof of Permission

Agent Gallery lets users discover Agents provided by Google, their organization, other users, Marketplace, and other sources. In the exercise, we also confirmed the flow of selecting an available Agent and querying business data.

The important point is that appearing in the list, being launchable, being able to read data, and being able to modify data are separate permissions.

For example, if you merely ask an Agent that uses BigQuery, Google Cloud’s data analytics platform, to “show me the top-selling products,” its permissions can generally be limited to the scope required for reading. There is no reason to grant the Agent’s execution identity permission to update or delete data or change permissions.

However, a description that calls it a “read-only Agent” is insufficient. You must verify the identity under which it actually runs, which datasets, tables, rows, and columns it can read, whether it can create query jobs, and whether it can export results externally. In other words, investigate what operations are effectively possible, not merely what the screen says.

2.2 Even Read Access Can Enable Data Exfiltration

Viewing data alone is not necessarily safe. If an Agent can read internal data and send it to the external Web, email, or document-sharing services, multiple small permissions can be combined to create an exfiltration path.

Permissions should therefore be evaluated not by individual role names, but by chains of actions such as the following.

Read internal data
  → Summarize the content
  → Send it to an external destination

As necessary, combine safeguards such as withholding external-sending Tools from read-only Agents, limiting export destinations, attaching confidentiality classifications to results, and inheriting the user’s ACL.

2.3 Connectors to Internal Systems and Documents Given Directly to an Agent Are Different

Connectors and Data Stores and Source Access Control describe how documents and ACLs from source systems can be ingested into a Data Store and how search can be controlled according to user Identity.

By contrast, the official documentation on sharing an Agent warns that people with whom an Agent is shared may be able to ask questions about Knowledge files added directly to that Agent even when they cannot access the original files directly.

This distinction is important.

Even if the intention is to “share only the Agent,” the Knowledge attached to it may expand the scope of information sharing. Before publication, run negative tests by asking questions under the recipient’s Identity and confirm that information they should not see is not returned.

3. Handling Video and Images: Make Multimodal Analysis Auditable

Company A’s financial materials alone do not reveal safety conditions or actual operational practices on site. Mr. Sato therefore adds site-inspection footage from the candidate company to the research materials. Analysis that handles images, video, and audio together with text is called Multimodal analysis. The information source changes from text to video, but the question remains the same: “Where in the original data can this judgment be traced?”

3.1 Trace an AI Explanation Back to a Location in the Footage

If a video audit responds, “There was a safety violation,” but does not identify which video and at what timestamp, a person cannot verify it. What is needed is not only the final conclusion, but also the chain of custody: the sequence showing where the evidence came from, how it was processed, and which conclusion it was used to support.

In the exercise, we reviewed audit results that combined video with other business data.

In Multimodal analysis, at least three types of errors should be distinguished.

1. Perception error: Misreading an object, person, text, audio, or time
2. Association error: Perceiving something correctly but linking it to the wrong store, device, or order
3. Rule-application error: Identifying the facts correctly but misinterpreting the applicable policy

3.2 Evidence to Record

The following JSON illustrates how to make a single video incident reviewable. The objective is not to create a complex format, but to enable a person to open the same scene and verify it again under the same rule.

{
  "asset_id": "video-20260904-001",
  "asset_hash": "sha256:...",
  "segment": {"start_ms": 42100, "end_ms": 48700},
  "observation": "Detected a person for whom protective equipment could not be confirmed",
  "perception_confidence": 0.82,
  "linked_context": {
    "site": "warehouse-east",
    "camera": "loading-bay-2"
  },
  "policy_reference": "safety-policy-2026-07",
  "review_status": "needs_human_review"
}

Separating the original footage’s hash, time range, observation, associated location, applicable rule, and review status prevents the model’s conclusion from being used directly for disciplinary action or warnings.

3.3 “No Violation” Is Not Proof That Everything Was Reviewed

Negative conclusions require caution. “No violation was detected” may mean any of the following.

• There truly was no violation
• Only part of the footage was analyzed
• A judgment could not be made because of darkness, obstruction, or missing audio
• The conduct covered by the rule was not defined
• The threshold was high and filtered out candidates

The report should also state the footage range analyzed, excluded segments, quality deficiencies, and unreviewed areas.

3.4 The Report-Editing Surface, Canvas, Is a Place for Review, Not a Finished Product

Here, Canvas refers to a workspace where Agent output can be edited as text and tables and organized into a readable report. Creating a readable report in Canvas makes it easier for people to review research results.

However, a polished appearance is not proof of correctness. Ideally, the review screen should display links from claims back to evidence, uncertainty, unverified items, the versions of data used, approvers, and update history.

Review so far

The research scope has expanded from the public Web to internal data and then to video. As a result, the report reviewed by Mr. Sato now needs to include each user’s access permissions, the version of the retrieved data, the time ranges of footage, and unreviewed segments. Adding more information does not automatically increase certainty; what matters is being able to trace the permissions and origin of each piece of information.

What remains: So far, the work has involved reading and analysis. Before proceeding to actions with side effects—such as contacting a candidate company or updating a customer relationship management system (CRM)—we need to turn human judgment into a technical stopping point.

4. Human-in-the-loop: Do Not Merely Add a Person—Stop Execution

4.1 Merely Having a Person Look at a Screen Does Not Create a Safety Mechanism

An Agent that connects multiple processes in sequence or under specified conditions is called a Workflow Agent. It can combine research, conditional branching, other Agents, connections to internal and external systems, and human confirmation. Workflow Agent and HITL Step provide mechanisms for requesting additional information and obtaining approval.

In the exercise, we also reviewed a Workflow that included human approval.

A safe Human-in-the-loop process requires the following conditions.

• No side effect occurs before approval
• The approver can see the target, changes, evidence, and risks
• If the content changes after approval, that approval cannot be used
• Rejection, expiration, or no response causes the process to stop safely
• A record remains of who approved what and when

The most important point in the diagram is that the review gate sits between “planning” and “execution.” Merely notifying a person after execution is not approval; it is an after-the-fact report.

4.2 Bind the Approved Content to the Executed Content

The system must guarantee that what appeared on the approval screen is identical to what is passed to the Tool. A common method is to canonicalize the execution plan and include its hash in the approval record.

The following example is a minimal implementation that checks whether the approved plan matches the plan immediately before execution. Rather than reading the code, focus on the property that “even a one-character change requires reapproval.”

import hashlib
import json

def plan_hash(plan: dict) -> str:
    canonical = json.dumps(plan, sort_keys=True, separators=(",", ":"))
    return hashlib.sha256(canonical.encode()).hexdigest()

def execute_if_approved(plan: dict, approval: dict):
    if approval["status"] != "approved":
        raise PermissionError("The plan has not been approved")
    if approval["expires_at"] < current_time():
        raise PermissionError("The approval has expired")
    if approval["plan_hash"] != plan_hash(plan):
        raise PermissionError("The plan changed after approval")
    return execute_once(plan, idempotency_key=approval["approval_id"])

This process confirms that the plan is approved, has not expired, and matches the approved content, while also using the approval ID to prevent duplicate execution. In practice, approver permissions, segregation of duties, signatures, revocation, and audit retention should also be added.

4.3 Design for Partial Failures Up Front

Suppose a process is instructed to “send emails to three people and update the CRM,” but the CRM operation fails after the second email is sent. If an automatic retry resends the messages to the first and second recipients, an incident occurs.

What is needed is not a simple binary success-or-failure state.

• An identifier that prevents the same request from being executed twice, or idempotency key
• A receipt for each operation
• State indicating how much of the process has completed
• Whether a compensating action is possible
• Conditions for handing the case over to a person
• A mechanism that proceeds only with the remaining operations during retry

4.4 Apply Change Management to Workflow Updates

According to Workflow sharing, when the owner updates the Live version, users with whom it is shared use the new version.

If the approver, destination, conditional expression, AI instruction text or Prompt, or Tool changes, the risk changes even when the Workflow name remains the same. Before releasing a version, perform a diff review, evaluation, and reapproval, and preserve the version in execution logs.

Review so far

We have transformed Human-in-the-loop from “a stage where a person looks at something” into “a stage that stops unless the approved plan is identical to the plan immediately before execution.” Expiration, rejection, content changes, partial failures, and duplicate execution should be designed up front with as much care as the successful path.

What remains: Even if the approval mechanism works correctly, an approver cannot make a meaningful decision if the analysis mixes facts with predictions or conceals missing data. Next, we will improve the quality of the decision inputs themselves.

5. Mergers and Acquisitions (M&A) Analysis: Separate Types of Statements Before Listing Numbers

We now move to the stage where Mr. Sato reads the assessment of Company A and makes a decision. In acquisition-candidate analysis, facts, requirements, interpretations, predictions, and decisions can easily become mixed together.

When all of these are written in the same tone, a prediction can look like an established fact. In tables and reports, distinguish them using types such as reported, calculated, assumed, projected, and decided.

In the exercise, we confirmed the process of creating a risk matrix and alternatives from multiple documents.

What matters is not how polished the table looks, but whether each cell can be traced to the evidence, formula, and assumptions from which it was derived. Recalculable items—such as totals, ratios, and discounted cash flow (DCF), which converts future cash flows into present value—should be rerun in code or spreadsheets, while the model should explain the meaning and assumptions of the formulas.

6. Source-Restricted Workbook (Notebook): Separate Citation Accuracy from Completeness

Here, Notebook refers to a workbook that collects the materials used for research in one place and allows questions to be asked within the scope of those materials. Its ability to restrict the scope to specified documents and answer with citations is powerful. The NotebookLM overview and Gemini Enterprise Notebook describe answers based on selected sources with inline citations.

However, the following are different.

• Citation accuracy: Whether the statement is genuinely supported by the cited passage
• Answer completeness: Whether all necessary sources and issues were addressed

Even perfect citations produce an incomplete overall answer if an important contract was never added to the Notebook. Conversely, even if all required documents are present, citing the wrong passage produces an inaccurate answer.

6.1 Freshness of an Ingested Static Copy

The Notebook Source API supports adding and managing sources. If an ingested source is a static copy, it may not change when the original document is updated.

Each source should therefore retain the following.

• URI and version of the original document
• Ingestion time
• Last-modified time of the original document
• Hash
• Resynchronization status
• Expiration conditions

Do not merely confirm that “there is a citation.” Confirm which version of the material was cited.

7. Python Execution: Make Calculations Reproducible and Do Not Hide Assumptions

7.1 Cleaning Data Does Not Restore the Truth

Business data contains missing values, inconsistent units, outliers, duplicates, and time misalignment. Using Python to transform the data makes calculations reproducible. However, imputing missing values is not magic that restores the lost true values.

In this diagram, imputed values are explicitly identified, correlation is separated from sensitivity during analysis, and uncertainty remains in the final decision. The lower section contains the audit trail for the source, transform, assumption, and result.

In the exercise, we also reviewed the process of cleaning data with Python before proceeding to analysis.

7.2 Record Missing-Value Imputation as a Hypothesis

Filling missing values with the mean or median makes calculations possible, but it can make the results appear excessively stable. For example, if missing revenue values are concentrated among stores on days when outages occurred, the data is not missing at random.

At a minimum, record the following.

• Original locations of missing values
• Imputation method and rationale
• Markers identifying imputed values
• Counts and distributions before and after imputation
• Sensitivity analysis using alternative methods
• Results when imputed values are excluded

7.3 Use Sensitivity Analysis to Assess the Robustness of a Conclusion

Even if one imputation method produces a conclusion, it is not strong decision evidence if a small change in assumptions reverses that conclusion.

For example, compare the following.

• Exclude rows with missing values
• Impute with the median
• Impute with the median for each group
• Construct a range using pessimistic and optimistic values

If Candidate A remains superior under every method, the conclusion is relatively robust. If the ranking changes by method, “additional research is required” may be the correct conclusion.

7.4 Do Not Leap from Correlation to Causation

In the exercise, we also reviewed correlation between variables.

Even a high correlation does not necessarily mean that A caused B. There may be a common cause, a time-series trend, selection bias, or reverse causality.

In the report, distinguish the observed correlation, potential confounders, and the additional experiments or quasi-experiments required to make a causal claim.

Gemini API Code Execution and the Code Execution Sandbox, which runs code in isolation from the Agent itself, have similar names but differ in execution methods, file reading and writing, state retention, time limits, and other characteristics. If analysis results will serve as evidence, preserve not only the code but also the input hash, library versions, random seed, time, execution output, and generated artifact hashes.

8. Research Agent: Stopping Conditions and How to Handle “Not Found”

A Research Agent is an Agent whose role is to follow multiple information sources and candidates and compile the research results. In Mr. Sato’s case, it examines multiple candidates in sequence rather than only Company A, making it important to define when it should proceed and when it should return control to a person.

8.1 Do Not Make “Stop If You Find a Problem” Merely a Conversational Request

Consider a task that researches multiple companies in sequence and stops when it identifies a serious risk. Simply writing one sentence in the Prompt may still allow the Agent to continue researching subsequent candidates or performing external actions.

Stopping conditions should be implemented as explicit state transitions.

stateDiagram-v2
    [*] --> Researching
    Researching --> NeedsReview: Serious candidate detected
    Researching --> NextCandidate: Within criteria
    NextCandidate --> Researching
    NeedsReview --> Stopped: Human stops
    NeedsReview --> Researching: Human resumes
    Researching --> Completed: All candidates reviewed

When the process enters NeedsReview, technically stop not only subsequent searches but also side effects such as email, updates, and approval requests.

In the exercise, we also reviewed a preview of results related to stopping conditions.

8.2 “No Misconduct Found” Is Not Proof of Innocence

When a search finds no serious issue, what can ordinarily be said is: “Nothing was found within the defined search scope, languages, period, and sources.”

Attach the following to negative conclusions.

• Company names, aliases, and former names searched
• Target languages and regions
• Target period
• Queries used
• Scope of sources
• Materials that could not be accessed
• Time of the final search

8.3 If Entity Resolution Is Wrong, the Process Fails Even When Citations Exist

If companies with the same name, parent and subsidiary companies, brand names, or pre- and post-acquisition names are confused, the citation may exist but still fail to provide evidence about the target company. Verify the company ID, location, official domain, parent company, and period, and stop automated judgment when ambiguity remains.

Review so far

We separated the research material for Company A into facts from original sources, internal requirements, interpretations, predictions, and decisions. We added source scope and freshness to Notebook citations, preserved inputs, missing-data handling, assumptions, and sensitivity for Python calculations, and gave the Research Agent a research scope and stopping conditions.

What remains: The individual processes have improved, but unless evidence and execution are connected into a single chain, context and versions can be substituted along the way. From here, we will define the strength of evidence and the handoff conditions between processes, then reconstruct the same case from beginning to end.

9. Do Not Stop at the Presence of Citations: Evaluate Evidence Strength in Stages

Reviews become easier when evidence quality is handled in stages rather than treating citation presence as a binary condition.

Read the following table from top to bottom as evidence becomes stronger. Merely having a URL is only an entry point for manual verification. By matching the target, period, and metric, fixing the version from the relevant time, and investigating independent materials and counterevidence, the evidence approaches a state suitable for important decisions.

Require higher stages for more important decisions, and stop with an “unknown” status when the requirement is not met.

10. Do Not Lose Information Between Processes: Define Handoff Conditions

The key to stabilizing a business Agent is to establish handoff conditions between capabilities.

This section contains several lists, but they are not four unrelated topics. They are “admission tickets” that the preceding process must pass to the following process. If an artifact does not meet the conditions, do not send it onward; return it to the preceding process.

From Evidence to Decision

• Claims are mapped to sources
• The target, period, metric, and unit match
• The source version and retrieval time are available
• Uncertainty and unverified items are identified

From Decision to Approval

• Facts, assumptions, predictions, and proposals are separated
• Alternatives and major risks are displayed
• The approver has the required authority
• The version of the decision materials is fixed

From Approval to Execution

• The approved content’s hash matches the execution plan
• The approval has not expired or been revoked
• The executing identity matches the target scope
• An idempotency key is available

From Execution to Audit

• A receipt exists for each operation
• Partial failures and compensation results are recorded
• Evidence, decisions, approvals, and execution can be connected through a common trace
• Versions of the Workflow, Agent, Tool, and policy are preserved

11. Return to a Single Case and Walk Through It from Beginning to End

We now return everything covered so far to the preliminary investigation of Company A introduced at the beginning and walk through it from start to finish. The business leader is Mr. Sato, and the research role is performed by the Research Agent. They are joined by a Tool that performs calculations, an approver, and Tools that contact the candidate company or update internal systems.

11.1 Turn “Research It” into Inspectable Conditions

An initial request such as “Research Company A, and if it looks good, proceed to the next step” leaves the meanings of “good,” “next,” and “proceed” ambiguous. Before starting, divide the request into the following elements.

• Target company: corporate ID, official name, aliases, location
• Research period: start and end dates
• Sources: official disclosures, regulators, trustworthy reporting, internal documents
• Metrics: revenue, profit, customer concentration, litigation, information security, and others
• Screening criteria: major litigation, sanctions, budget overruns, and others
• Output: claims, citations, unverified items, options, recommendation
• Permitted next action: whether only additional research is allowed or a draft interview request may also be prepared
• Actions requiring human approval: sending email, sharing data, processing contracts

No code has been written at this point. Nevertheless, this is critical design work that makes subsequent search, evaluation, and approval possible.

11.2 Turn Research Results into an Evidence Packet

Rather than writing a long concluding narrative from the outset, the Agent creates a reusable bundle of evidence called an Evidence packet.

Evidence packet
├─ Confirmed information about the target company
├─ Supporting passage for each claim
├─ Source version, retrieval time, and authority
├─ Refuting or contradictory material
├─ Items not found and the scope searched
├─ Gaps caused by missing data, poor quality, or ACL restrictions
└─ Structured data used in calculations

Information that “was not found” is also included in the artifact. Do not let the Agent fill blanks with speculation; pass them onward as areas requiring additional research.

11.3 Perform Analysis with Fixed Inputs and Assumptions

Before calculating revenue growth rates or acquisition multiples, establish the target period, currency, accounting standard, exchange rate, and missing-data treatment.

For example, if Company A and another acquisition candidate, Company B, have different profit margins, the difference may result not from the strength of their businesses but from different classifications or treatment of one-time expenses. The Agent can calculate quickly, but comparability must be ensured through human judgment and explicit rules.

Analysis results should include ranges rather than only point estimates.

11.4 A Review Packet Should Help a Person Decide

Rather than giving the approver one long document, display the following on the same screen.

1. Proposed action
2. Target and scope of impact
3. Key evidence
4. Assumptions and uncertainty
5. Contrary evidence
6. Alternatives
7. What happens if approval is withheld
8. Exact arguments planned for execution

Human-in-the-loop here is not a mechanism for shifting the AI’s responsibility onto a person. It is an interface that shows the difference between Evidence and Action so that a person can make a meaningful decision.

11.5 After Execution, Return a Receipt Rather Than “Succeeded”

If an interview request was sent, preserve the recipient, template version, message hash, external system message ID, and sending time. If the CRM was updated, preserve the before-and-after values, record version, and response ID.

The completed system should ultimately be able to connect the following chain.

Request
→ Search criteria
→ Sources used
→ Claims
→ Calculations and assumptions
→ Recommendation
→ Content reviewed by a human
→ Approval
→ Execution arguments
→ External system receipt

If this chain remains intact, you can explain why the outcome was good, why an incident occurred, and how to improve the process next time.

12. Prevent Degradation After Release: Build Continuous Assurance into Operations

Even a Workflow that worked correctly once can behave differently when its sources, permissions, model, Tools, or policies change. Quality assurance should therefore become an operational cycle, not merely a pre-release test.

12.1 Detect Changes

• Connector synchronization delays increased
• The URL or version of a key source changed
• User affiliations and ACLs changed
• The Agent or model version changed
• A Tool schema or external API changed
• Workflow conditions or approvers changed
• The distribution of production data changed

12.2 Select Tests Based on the Change

There is no need to run every test for every change. Select tests based on the affected scope.

12.3 Make Human Review Measurable as Well

Do not rely on “a person looks at it in the end, so it will be fine.” Improve the quality of review itself.

• Percentage of cases in which approvers opened the evidence
• Reasons for corrections and returns
• Oversights discovered later
• Time required to review one case
• Differences in judgment depending on whether uncertainty is displayed
• Low-risk items that can be moved to automation

Do not treat people as a final, universal breakwater. Build a mechanism that learns where decisions are easy to make and where reviewers tend to miss things.

Review of the complete case

Mr. Sato’s request was decomposed into a target and research conditions, then transformed into an Evidence packet, reproducible analysis, a Review packet, an approved execution plan, and Receipts from external systems. At every stage, the version and evidence from the preceding artifact were carried forward. After release, the required tests are rerun in response to changes in documents, permissions, models, Tools, and policies.

What remains: To take this long process into practical operations, it must be condensed into commitments to uphold, metrics to monitor, and an implementation sequence. The remaining sections present that operational version.

13. Commitments to Uphold in Production

We will now convert the design above from explanations of individual capabilities into “conditions that must always be upheld as part of the business process.” The left column states the commitment, and the right column explains how to verify it.

Metrics to Monitor

• Percentage of claims with evidence
• Match rate between claims and cited passages
• Rate of target-company and period mix-ups
• Number of source freshness violations
• Number of failed ACL negative tests
• Percentage of metrics containing imputed values
• Percentage of conclusions reversed by sensitivity analysis
• Number of plan mismatches after approval
• Duplicate side-effect rate and partial-failure rate
• Percentage of cases traceable from evidence to execution

14. When Implementing, Start with Small Tasks Backed by Strong Evidence

Begin with Read-Only Research

Research public information, map claims to sources, and stop at human review. Decide in advance what constitutes sufficient evidence.

Next, Connect Internal Data

Verify per-user viewing permissions, an Agent-specific execution identity, constraints on search conditions, and confidentiality classification of results. When sharing settings change, also test that information that should remain hidden is not returned.

Add Calculations and Multimodal Analysis

Preserve input hashes, transformations, assumptions, calculation results, and video time ranges. Display missing data and uncertainty instead of hiding them.

Turn It into a Workflow

Fix the execution plan and place approval immediately before side effects. Test expiration, rejection, partial failures, and duplicate retries.

Progress to Continuous Assurance

Whenever the version of a source, model, Agent, Tool, Workflow, or policy changes, run evaluations and sample reviews. Quality does not end with a one-time acceptance test.

15. Briefly Resolving Common Misconceptions

“It Has a Citation, So It Is Correct”

A citation is an entry point for traceability. Verify that the target, period, metric, unit, and relevant passage match the claim.

“The Sources Are Restricted, So the Answer Is Complete”

Fidelity to a restricted scope is different from having all required sources.

“It Is a Read-Only Agent, So It Is Safe”

If it can send the information it reads externally, it has exfiltration capability. Evaluate combinations of permissions.

“It Has Human Approval, So It Is Safe”

Approval must occur before side effects, the reviewed content must be bound to the executed content, and rejection or expiration must stop the process.

“It Was Calculated in Python, So It Is Objective”

The calculation can be reproduced, but judgment remains in input selection, missing-value imputation, outlier treatment, and causal interpretation.

“No Problem Was Found, So There Is No Problem”

It may only mean that nothing was detected within the searched scope. Attach the scope and limitations to the conclusion.

16. Practical Checklist

Evidence

• Important claims can be traced back to the relevant passages
• The target, period, metric, and unit have been verified
• The source retrieval time, version, and hash are preserved as appropriate for the use case
• Counterevidence and unverified items are displayed
• The search scope for “not found” results is recorded

Permissions

• Gallery visibility, Agent execution, Data access, and Action are treated as separate permissions
• The combination of read access and external transmission is evaluated
• Connector ACL boundaries are distinguished from direct Knowledge boundaries
• Negative tests are performed under the recipient user’s Identity

Analysis and Decision-Making

• reported, calculated, assumed, projected, and decided are separated
• Imputed missing values are marked and sensitivity analysis is performed
• Correlation and causation are separated
• Code, inputs, libraries, and results can be reproduced
• “Additional research” can be selected when uncertainty is high

Approval and Execution

• Approval occurs immediately before side effects
• The approver is shown the target, differences, evidence, and risks
• The approved content and execution plan are bound with a hash
• Expiration, revocation, or rejection stops the process
• Idempotency, receipts, and partial failures are handled

Operations

• Agent, Tool, Workflow, and policy versions are recorded
• A common trace connects evidence through execution
• Regression evaluations are performed after source or model updates
• People sample and review high-impact cases

Conclusion

The value of the Business Builders Track is not a feature list saying that AI can search the Web, read BigQuery, understand video, or execute Python.

Collect evidence. Verify its correspondence with claims. Preserve assumptions while preparing data. Separate facts from predictions. Obtain approval in a form people can understand, and execute only that approved content exactly once. Then make the entire path explainable afterward.

Only with this flow does the exceptionally capable new hire’s report become evidence robust enough to support decision-making. By also binding approval strictly to execution, AI can progress from “a screen that answers questions” to a business system that an organization can use responsibly.

Official Documentation

• Gemini Enterprise Documentation
• Grounding Overview
• Grounding with Google Search
• Grounding Metadata
• Web Grounding for Enterprise
• Agent Gallery
• Create BigQuery Data Agents
• Connectors and Data Stores
• Configure Source Access Control
• Share an Agent
• Workflow Agents
• Use HITL Steps
• Share a Workflow Agent
• Gemini Enterprise Notebook
• Notebook Source API
• Gemini API Code Execution
• Agent Platform Code Execution Sandbox