MCPs have changed the game when it comes to getting context on why and how something was built the way it was. But they aren't perfect. Not until I can get an MCP into the brain of the person who built the thing.

I've had to dive deep into marketing automation flows that are very complex and not built by me. And even with tools that can help me understand what's happening inside a system, there's a limit to how much context I can reconstruct after the fact. I can see pieces of what something does, but I often don't know how all the pieces fit together or why it was built that way.

Which has me thinking: it costs more to reconstruct context than it does to create it in the first place.

These things could have saved me a lot of time. And honestly, not just me! When I start trying to understand why or how something was built, I have to get very noisy in Slack to figure it out.

HubSpot's strength is also part of the problem

HubSpot is a non-technical marketer's dream. You can drag and drop a seemingly infinite number of actions into an automated flow without a developer getting involved. (I've done this!)

For example, someone fills out a form on your website. You can:

Pretty neat! Before you know it, you end up with workflows like this:

This is actually only a 30% view of a HubSpot workflow. A very large screen couldn't capture every action.

The workflow actually calls LLMs (yes, multiple) to enrich leads, and pushes to other automation tools (n8n) to enrich further and post Slack messages.

This workflow, given the vast amounts of steps, if/thens, pushes and pulls to other systems, with no documentation or shared knowledge how it all works is very scary. What if the person who built it left? What if something in it breaks? How do you even begin to parse through the 30% view of the workflow that stretches far and wide to fix it? What if you want to iterate!?

This is a real business scaling issue.

Updating automated Slack messages took 5 people

I once wanted to update the content in an automated Slack message that posted new leads from the contact sales form in a public Slack channel. The Slack message included a lot of emojis. With the emojis, it made the channel feel a little noisy.

The proxy HubSpot MCP we had built couldn't actually help me identify where this Slack message was firing. So I had to manually click through and scroll through very large workflows.

As I was on the hunt, I found five broken steps across five different workflows. Slack messages were posting to archived channels. Who knew!

In the deep dive session, I finally found that the particular message I wanted to edit was actually living in another automation tool (n8n). Which is why the proxy MCP couldn't find it.

Since I didn't build this particular workflow, I didn't have access to that n8n project. So, I had to pull in some help. And, the person that did create this workflow no longer worked for the company which added more complexity.

It took four additional people to finally find the automation and get me access to it.

I then edited the message (deleted the emojis) and tried to fire a test. I actually wanted to see the full flow from the form all the way down to Slack.

My test never came through.

My best guess was that one of the multiple LLMs firing across different systems filtered me out as a non-serious buyer before my test contact ever made it to the n8n webhook.

Because I didn't build these automations, it was really difficult for me to know how anything worked for sure. So, back into the workflows I went to figure it out.

The cost of no context

I think there's a real cost to building systems without documenting or sharing with your team how they work and why they work the way they do.

When that context isn't available, the next person has to reconstruct it.

In the example I shared, that also meant bringing in other people to help piece it all together.

It feels like an expensive way to learn how systems work.