How I AI: Block's 3-Step Workflow for Data Analysis, E-commerce, and Custom AI Tools with Goose

A messy farm-stand CSV turns into a revenue analysis, a dashboard, a populated Square catalog, and a live payment link in under an hour of demos. The interesting part is not that Goose can write code. It is that the same agent keeps crossing boundaries from local analysis into business systems while humans decide where approval and review still matter. In this episode of How I AI, Block engineering leaders Jackie Brosamer and Brad Axen demonstrate three Goose workflows: analyzing a farm-stand CSV, creating catalog items and a payment link through a Square MCP, and building an email MCP from a working Python script.

Jackie describes AI adoption at Block as both bottom-up experimentation and top-down support. Engineers adopted coding tools quickly, while sales and business users wanted faster ways to work with leads, reports, and operational data. The harder organizational question is which systems agents may access and which actions require confirmation.

Goose is Block’s open-source AI agent for multi-step tool use. It runs locally, connects to external systems through MCP servers, and chains together shell commands, code generation, APIs, and browser actions. The demos escalate from local analysis to payments and email, making the changing permission boundary easy to see.

Turning a raw CSV into analysis and dashboards

Jackie uses Goose for exploratory analysis that would normally involve spreadsheets, pivot tables, Python scripts, and repeated context switching. Instead of manually cleaning data, she asks Goose to inspect a CSV, write analysis code, execute it locally, and package the results into something shareable. The mechanics are automated, but the interpretation still stays with her.

Jackie's farm-stand CSV contains item names, quantities, dates, and prices. The raw-CSV analysis workflow shows how Goose inspects the file, writes and runs analysis code, and produces a reviewable report without hiding the intermediate work.

Prompt Goose in plain English

Jackie starts with a local CSV containing July farm-stand sales data and gives Goose a short natural-language instruction instead of writing code. The prompt asks Goose to use Pandas to identify the highest-revenue items, the busiest days of the week, and other meaningful patterns.

Use Pandas to identify the items with the most revenue, the busiest days of the week, and other patterns in this file.

From that single prompt, Goose searches the local workspace for the file, generates Python analysis code, executes the script, and prepares a report. Jackie notes that in a company setting, the agent should only receive access to the directories and files required for the task rather than broad filesystem access.

Watch the agent assemble its own analysis environment

One useful part of the demo is seeing the intermediate actions instead of only the final output. Goose chains together several ordinary developer tasks humans usually perform manually:

1. File discovery: Goose used ripgrep to locate july_data.csv in the local working directory.
2. Code generation: Goose wrote a Python script using Pandas for the requested calculations.
3. Environment setup: When a dependency failed, Goose created a virtual environment and retried the analysis. Jackie jokes that this drifted into cursed virtual environment territory, but it also showed how agents can debug local tooling problems on their own. Environment changes and installed packages still need review and isolation.

Generate insights and a shareable report

Once the script ran successfully, Goose returned a summary and several observations from the farm-stand dataset:

• Revenue: Berries produced the most revenue in the sample.
• Busy days: Thursday and Saturday had the highest sales in the sample.
• Other patterns: The report highlighted cherries and weekly variation.
• Suggested follow-up: Goose proposed additional questions around margins, Friday sales behavior, and pricing strategy. Jackie points out that the CSV alone cannot answer all of those questions and that acting on the recommendations would still require business context.

Jackie then asks Goose to turn the analysis into a local webpage. Goose generates an HTML report with Plotly charts and opens it in the browser automatically. The dashboard is rough around the edges, but it shows why these workflows appeal to non-technical teams inside Block. Employees can create lightweight visual reports themselves instead of waiting on a data specialist. The workflow also reinforces one of Goose’s core design choices: everything runs locally rather than inside a hosted notebook environment.

Using MCPs to write into a live commerce system

After the local analysis, Brad moves into a higher-risk workflow by connecting Goose to Square through MCP. Instead of only reading data, the agent now has permission to create records in an external business system. The demo uses a sandbox account, which is the boundary you would want before allowing financial or operational writes.

Brad explains MCP as the protocol that gives an AI agent tools and access to outside systems. Goose can inspect available operations, decide which ones are relevant, and orchestrate API calls on its own. The setup still needs guardrails: least-privilege credentials, explicit confirmation for writes, and restrictions around sensitive operations like payments.

Create a product catalog from messy operational data

Brad starts with an empty Square catalog and gives Goose the same CSV from the farm-stand analysis. Instead of demanding a perfectly formatted import template, Goose reads the file, infers the structure, and maps the contents into Square catalog objects.

Can you read through this data and use it to create items in my Square dashboard?

This is where the workflow becomes more interesting than a standard CSV importer. Goose is effectively acting as data duct tape, as Jackie describes it. The CSV does not need exact column names or rigid formatting rules. The agent interprets the data and translates it into the fields Square expects. A human still needs to review generated products, prices, categories, locations, and duplicate behavior before approving the write.

In the demo, the catalog appeared in Square with products, prices, and categories. Jackie calls this kind of cross-system mapping "data duct tape."

Generate a live payment link from natural language

Once the catalog exists, Brad pushes the workflow further by asking Goose to create a payment link for three pumpkins. The request is intentionally conversational rather than API-shaped.

Okay, let's make a payment link for three pumpkins.

Goose retrieves the catalog items, chooses a business location, and generates a payment link. I point out how different this feels from a form-heavy workflow, but the operator still needs to verify quantity, price, location, and test-versus-live state. The e-commerce catalog workflow makes that translation from messy input to strict commerce records inspectable.

Building a custom email MCP from a working script

The final workflow shifts from using an existing MCP to creating a new one. Brad builds a Mailgun-backed email tool so Goose can send the payment link automatically. This part becomes a realistic example of agent-assisted development, complete with setup problems, debugging loops, SDK mismatches, and moments where Brad redirects the model.

Start with a standalone Python script

Brad’s first move is deliberately narrow. Before mentioning MCP, he asks Goose to create a Python script that sends a test email through Mailgun using credentials stored in a local environment file. He explains that proving the underlying function works first makes the later MCP packaging step easier.

Create a Python script in this scaffolded package that sends a test email through Mailgun. Read credentials from the local environment file without displaying or committing them.

Goose generates the script, attempts to inspect the environment file, gets denied for security reasons, and proceeds using the instructions Brad provided manually. After updating the recipient address and resolving environment details, the script successfully sends a test email. I note that the process replaces the usual developer loop of reading documentation, wiring together boilerplate, and troubleshooting APIs.

Wrap the script as an MCP tool

With the core email function working, Brad copies reference code from the latest MCP Python SDK documentation and asks Goose to expose the tested function as a send-email MCP tool.

Use this reference code to expose the tested email function as an MCP tool.

This section highlights one practical reality of coding with agents: current documentation matters. Brad explicitly feeds Goose the latest SDK examples because the model’s built-in knowledge does not fully cover the current MCP specification. Goose combines the example code with the existing Mailgun script and generates an MCP server implementation.

Debug the integration instead of rewriting it manually

The first attempt fails with a code error when Brad tries to load the MCP into Goose. Instead of stepping through the implementation line by line, he pastes the error back into the model and lets Goose revise the code. Brad says he usually lets the model attempt the first fix because it is often faster than investigating himself. If the model keeps looping without progress, he takes over.

After a few iterations and one small manual change from Brad, the MCP server starts successfully and appears as a Goose extension. The new send_email tool is now available to the agent. Even with the successful demo, Brad emphasizes that a production version would still need recipient restrictions, rate limits, credential management, and confirmation prompts before messages are sent.

Reconnect the workflow and send the payment link

Brad then enables the new extension inside the earlier Square payment-link session and asks Goose to email the purchase link to a demo address.

Send the payment link to my allowlisted demo address after showing me the recipient, subject, and message for confirmation.

Goose retrieves the payment link, drafts the message, and sends it only after the email tool is enabled and the recipient is confirmed. The custom Goose email-tool workflow preserves the useful sequence: prove a standalone script, wrap it as an MCP tool, debug the integration, and reconnect it with explicit approval.

Move from local analysis to external actions carefully

The demos progress through three increasingly sensitive boundaries: reading local files, writing commerce records, and contacting another person through email. Each stage requires tighter permissions, clearer confirmation flows, and more safeguards than the one before it.

What Goose does well is remove friction around orchestration. It can discover files, write scripts, troubleshoot dependencies, connect APIs, and package tools together faster than most people would manually. The human operator still owns the important decisions: whether the data is trustworthy, whether generated code is safe, whether catalog entries are correct, and whether actions should happen at all.

The strongest pattern worth copying from this episode is the incremental escalation. Start with a reversible local task. Add one external system in a sandbox. Require the agent to show proposed writes before executing them. Only then layer on tools like email or payments. Goose is especially effective for stitching together messy operational workflows that normally involve too many manual steps and too much formatting work. Human judgment still matters most anywhere the workflow touches money, customers, permissions, or ambiguous business context.