Andy McCutcheon started as a lifecycle marketer at Block who leaned technical: platform migrations, campaign data analysis, personalization syntax, and the practical work of making marketing systems run better.
Then coworkers started asking him questions about AI. Those questions became weekly office hours. The office hours became biweekly sessions. Eventually, Andy moved into a formal AI role serving Block's go-to-market and marketing teams. His mandate now spans sales and marketing, where teams bring internal tooling ideas and work with him to make them faster, smarter, and more useful.
The operating lesson from the episode is simple: AI adoption becomes real when individual builders create shared surfaces. At Block, that means live building sessions, an internal skills marketplace, web apps that can become MCPs, model routing that respects cost, and agent handoff rituals that make work durable across sessions.
The role came from demand, not a new org chart
Andy describes his job as AI solutions for Block's go-to-market and marketing org. Most of the work is collaborative. A team has a use case, they sit down together, and the output is often an internal tool that helps the team move faster or make better decisions.
That role emerged organically. Andy had already built credibility as a technical lifecycle marketer, then started exploring AI more seriously about a year and a half before the recording. As more people came to him with questions, he turned the demand into office hours and training sessions. Later, he made the case to split his time 50/50 between lifecycle work and AI work, then moved into AI more fully as demand kept accelerating.
The broader Block context matters. Andy says the company has a strong builder culture, with Jack Dorsey advocating that everyone at the company is a builder. That gave him enough permission to turn curiosity into a real internal function.
Make AI work observable
Andy's enablement philosophy is deliberately casual. AI can feel intimidating for non-technical teams, so his office hours are low-pressure by design. Sometimes only a few people show up. Sometimes people come without a question and learn by listening to someone else's problem.
His strongest format is more concrete: he shares his whole screen, opens Cursor or Claude Code, starts from zero, and asks the group what to build. Someone might suggest an ROI estimator for Square sellers. Andy builds it live, narrating when he stays in a simple prompt and when he switches into a more structured planning mode.
That is the difference between showing a finished artifact and teaching a workflow. The finished artifact proves something is possible. Watching the build makes the work learnable.
Shared infrastructure turns experiments into products
One of the most important parts of Block's AI environment is that builders have somewhere to put the work. Andy describes an internal agent monorepo in GitHub with skills and MCPs that render into an internal skills marketplace. He estimated there are around 3,000 skills, many maintained by engineering teams, with marketing-relevant skills for writing, design intelligence, and quality consistency.
That infrastructure changes the emotional loop for non-engineer builders. A personal workflow can become a company skill. An MCP can move from one person's machine into a shared repo. A marketer can contribute something that sits next to engineering-maintained tools.
Andy also treats internal marketing as part of enablement. In Block's AI Builders Slack community, he spotlights people who ship their first app or workflow. That creates an inspiration loop. One person's tool helps another team imagine a version for their own use case.
The harder problem is discovery. In a large company, it is difficult to know what has already been built, which tools are still current, and where a new idea should live. Block solves part of that with Slack, internal surfaces, canvases, bookmarks, and the skills marketplace, but Andy is clear that wrangling the full map is still a challenge.
Start with a web app before MCP
Nick framed one of the core problems as moving from single-player to multiplayer: a tool that works for the builder has to become usable by the team. Andy's default answer is practical. Start with a web app.
That sequence gives teammates a direct surface to use. Their questions reveal which assumptions were only obvious to the original builder. Once the workflow makes sense to real users, the same capability can be extended into MCPs or agent skills for people who prefer to work from Claude Code, Goose, Cursor, or another agentic environment.
Andy has already done this with internal applications that later gained companion MCPs. The web app gives people a reliable product surface. The MCP lets the same workflow live closer to where some users already work. The durable lesson is to learn with the simplest shared surface first.
Treat cost as a routing problem
Andy is also building AI infrastructure for his own workflow. At the beginning of the episode, he describes an MCP layer that routes individual prompt tasks to different models based on complexity. Quick lookups can go to Haiku. More matching-based work can go to Sonnet. More ambitious or complex work can go to Opus.
The motivation is not abstract optimization. Andy sees AI cost becoming a real constraint, and he does not want every task to default to the strongest model.
The router sits between the prompt and the model endpoint. Andy says the latency has been smaller than expected, though he had not tested it in production yet at the time of recording. The bigger idea is useful either way: model choice becomes part of the system design, not a manual decision the user has to make every time.
Give agents a handoff ritual
Andy has shipped a lot of internal tools. When Nick asked for a count, Andy estimated at least 40 Databricks apps and more than 50 total applications, MCPs, prototypes, and related systems.
One of his current personal unlocks is smaller but highly reusable: custom Claude Code slash commands. He uses two foundational commands called "wrap it up" and "boot up."
"Boot up" starts the next session by finding the files created by the previous wrap-up. That solves a common problem in agent work: the context window ends, a new session starts fresh, and the builder has to reconstruct what happened. Andy's workflow turns that reset into a managed handoff.
The pattern also points to where the AI marketing engineer role is going. Andy wants to define the role more clearly inside Block and connect the many people doing similar work across legal, paid marketing, and other teams. Some of that connective tissue might become a formal team. Some might remain an internal network. Either way, the role is less about using AI in isolation and more about turning useful work into repeatable infrastructure.
Listen to the full conversation
Listen to the full episode for Andy's breakdown of Block's builder culture, the internal skills marketplace, live-build enablement, model routing, web apps versus MCPs, and the agent handoff rituals he uses to keep long-running build work moving.
