Hands-On With Coalesce MCPs Part 3: Built-In Agents and Production-Grade Playbooks

In part 1 of this blog series, we looked into how you can use Coalesce MCPs to speed up data engineering and governance workflows. In part 2, those prompts were packaged into skills to make them reproducible. This final part looks at how they can be productionized, either as playbooks or built-in AI agents in products.

Below are a few practical ways we're doing this at Coalesce. Some workflows are core enough to build directly into the product. Others are domain-specific, and we've built production-grade playbooks and skills on top of our MCPs.

While built-in agents require significant product work, production-grade playbooks can be developed by domain experts such as solution engineers who often have the best understanding of customer problems.

Built-in agents

Built-in agents are workflows that are part of the core product and already include built-in guardrails. Examples are the agents built inside Coalesce Transform and Quality. They run where the work already happens and are tightly integrated in the product experience.

Coalesce Copilot

Coalesce Copilot lives within the development workspace. You describe what you want in natural language, and it turns that into governed transformations, writes SQL, builds staging, dimension, fact, and view layers, and keeps lineage intact under the roles and audit already in place. It captures its context automatically from the subgraph you are working in, so it knows the surrounding models without being told, and whether it can change anything or only propose can be controlled by a read/write toggle.

Because it builds inside the Coalesce Transform workspace, it produces real transformation code with column-level lineage and your team's standards already applied. This also means that changes can be deployed through the normal workflow rather than a draft that someone has to rework first.

Scout

Coalesce Quality's Scout agent works in the background as an always-on data SRE. It runs as asynchronous agents that kick off their own jobs, working through every open issue around the clock, triaging each by importance, and surfacing a recommended action along with the evidence. By the time you open an issue the investigation is usually already done, so you stay in the loop by reviewing conclusions rather than chasing every alert. In one example, an anomaly monitor fired on a sharp drop in row count, and within seconds, Scout had traced it to an intentional code change, linked the relevant commit, and proposed marking the issue as expected.

While much of the same analysis is available through the MCP, running the investigations in the background as an agent enables new workflows, such as presenting users with a sorted list of recommended actions across all issues.

Production-grade playbooks and skills

Not every production workflow belongs in the product. When something is specific to how your team works, it's often a better fit to build it on top of the existing MCP as a playbook. While a skill packages a task so it runs the same way every time, we think of a playbook closer to production, often running at a set schedule or guiding end-users' flow through a defined flow.

Customer issue triage playbook for quality

One of our internal production playbooks handles issue triage for our data observability platform, for example, catching when a customer's integration goes down or when other anomalies appear in their workspace. It runs each morning against the workspace that monitors our production systems, the ClickHouse tables, Postgres, and job queues, and by morning, it has worked through the open issues and posted a prioritized summary to Slack, replacing an otherwise lengthy manual investigation.

It encodes the logic we'd normally apply when running these investigations by hand, grouping related issues, querying the data, and reading logs from the production databases, among other checks.. It also drafts likely root causes as summaries ready to share with customers, and tags the person or team on rota (AKA on-call rosters) that week.

That summary is the output of a run that would otherwise be an hour of manual triage.

Data governance rollout skill in the data catalog

The same idea applies to governance. Coalesce's solution engineering team has distilled best practices from hundreds of customer engagements into a set of governance skills, packaged as a sequenced rollout playbook that guides a team from zero to a governed catalog in eight to twelve weeks.

It has built-in best practices, such as writing descriptions before assigning owners, so owners don't inherit an empty to-do list. It starts by classifying assets into tiers, capping Tier-1 at roughly 5% of tables and picking them from real usage signals, the most-queried tables, and most-consumed dashboards, rather than gut instinct.

From there, each phase has an owner, an effort estimate, and a measurable exit criterion that the agent can check itself.

• Ownership first. For each unowned Tier-1 table, the agent pulls an evidence bundle, its top query authors, and lineage neighbors, then assigns owners until at least 95% of Tier-1 assets have one.
• Metadata next. Descriptions are drafted in bulk and routed to the owner for approval rather than auto-applied, then written back in batches, with PII flagged on regulated columns.
• Lineage and quality. Later phases validate lineage and surface-quality results for each asset
• Data products and coverage. A handful of curated data products are promoted, and a scorecard tracks coverage across the whole scope.

When to use which

The steps often look like this: We start with a prompt for exploration, then build skills for repeatable tasks, create playbooks for repeatable workflows, and finally, a built-in agent for workflows that fit better within the product.

Not all prompts should be skills, and not all playbooks make good product agents. In the examples above, having Copilot and Scout as built-in agents makes sense as they capture context from the UI and underlying platforms, the subgraph you are editing, or the full state of the monitoring environment, so you are not feeding it context by hand.

Building on the MCPs is more flexible and better when the workflow is specific to a team or spans tools. The MCPs plug into a client like Claude, chain together with other MCPs already in use, and let you assemble bespoke workflows that a fixed-in-product agent cannot. That is where you encode your own sequencing, anti-patterns, and exit criteria. The catalog rollout is a good example, since the phases, tiers, and order are specific to each organization.

Summary and what's next

This series has covered how to go from getting started with MCPs for data engineering, to automating workflows with skills, to deciding what to put into production.

• Part 1 used the Coalesce MCPs ad hoc, one prompt at a time.
• Part 2 packaged those prompts into skills, so a task runs the same way every time.
• Part 3 (this post) covered the two ways that scale, built-in agents for the common workflows, and production-grade playbooks and skills for the ones specific to a team.

Most teams use a mix of all of these. What ties them together is that they work on the same metadata, because Transform, Catalog, and Quality sit on a single data operating layer, which lets a single run audit ingestion, assign ownership, check quality, and walk the lineage end to end.

Get started with Coalesce MCPs

If you are already a Coalesce customer, reach out to your Coalesce account lead or submit a contact request to talk through playbooks and agent use cases.
If you are not a Coalesce customer yet, book a demo to see Transform, Catalog, and Quality in action.