I'm Building an AI-Powered Delivery Engine. Here Is Where It Is Right Now.

GTM Layer is a two-person consultancy that manages more client work than it has any right to at this pace. I spend most of my time in client meetings, scoping architecture, building in HubSpot and Clay, and moving between projects at a speed that should not be sustainable. Luis, our Head of Operations, keeps everything else running. He picks up the delivery tasks, manages the admin, coordinates timelines, and makes sure nothing falls through while I am bouncing between calls and builds.

We are good at what we do. But the operational overhead of running a consultancy at this intensity is real. There is a constant stream of information flowing through meetings, emails, Slack threads, and internal conversations. Keeping all of that organised, actionable, and visible to both of us is a job in itself.

So I am building a system to handle it. Not a finished product. A work in progress that we are actively iterating on, using Claude, ClickUp, Fathom, and Miro. The goal is to create enough operational space that Luis and I can focus almost entirely on client delivery and on building the kind of tools and systems we actually enjoy working on.

The Information Problem

The challenge is not that information does not exist. It is that it exists everywhere and it moves constantly.

A client mentions something in a meeting on Tuesday. A follow-up email comes in on Wednesday with a slightly different angle on the same issue. By Thursday there is a Slack message referencing something from both. Each of those touchpoints contains context that matters, but none of them are connected unless someone manually pulls them together.

This is the same problem we solve for clients in the revenue operations space. Fragmented data across multiple systems, no single source of truth, and decisions being made on incomplete information. The difference is that in a consultancy, the "data" is conversations, and the "systems" are whatever tools you happen to have open at the time.

I am trying to build a system where all of that information flows into one place, gets structured automatically, and becomes something Luis and I can act on without spending hours on admin. And I want it to get smarter over time by capturing data from every source available to us.

Fathom to ClickUp: Meeting Intelligence Into Structured Tasks

The first piece of the system connects Fathom directly to ClickUp. After every client meeting, the automation scans the transcript, identifies action items and commitments, and creates tasks in ClickUp.

The important bit is not just that tasks get created. It is where they land and what they contain. Each task routes into the correct client project automatically. It gets screened against existing tasks so we do not end up with duplicates. And the task description includes the full context: what was discussed, who raised it, what the expected outcome is, and any relevant background from the conversation.

A task that says "fix the workflow" is useless two days later. A task that says "Update the deal stage workflow to include a 'Pending Legal Review' stage, triggered when the custom property 'Contract Status' is set to 'Under Review'. James flagged this as blocking their Q2 pipeline reporting" is something either of us can pick up and start working on immediately.

This is the same principle we apply when building enrichment pipelines for clients. Layering context onto data so the person acting on it has everything they need without going back to the source. In a Clay table, that means enriching a company record with technographics, hiring signals, and funding data before a rep ever sees it. In our delivery system, it means enriching a task with meeting context before Luis or I ever open it.

The automation is on its third iteration. The first version created too many tasks from conversational noise. The second was too conservative. We are still refining the balance, and that iteration is part of the process.

Nightly Email Triage: Catching What Meetings Miss

The second automation runs a nightly scan of my Gmail inbox and sent emails, looking for client-related threads that contain something actionable.

This goes beyond explicit requests. Yes, it catches the obvious ones: a client asking for a timeline update, or me replying that I will send something by Friday. But it also picks up the less obvious signals. A client saying "I was thinking about whether we could..." is not a direct ask, but it is an idea that should land on our backlog. A client describing a problem they are running into is not a task request, but it is something we should be tracking and thinking about.

The scan distinguishes between informational emails and ones that imply action, and it creates ClickUp tasks with the email thread context, the client name, and any implied deadlines. The goal is that suggestions, problems, and half-formed ideas get captured alongside the explicit asks, because those are often where the most valuable work comes from.

Like everything else in this system, it is a work in progress. The triage occasionally flags something that is purely conversational, and it sometimes misses nuance. But it catches things that would otherwise disappear into an inbox, and that alone makes it worth iterating on.

Daily Work Digests for Luis

This is one of the pieces I am most excited about developing further.

I spend several hours a day in client meetings. Those meetings contain the context that drives everything: the technical decisions, the strategic direction, the client's priorities, the things that were said between the lines. That context is critical for Luis to do his job well, but having him sit in on every meeting is not a realistic use of his time.

The daily digest pulls together everything relevant from the day's meetings, emails, and task updates, and delivers it to Luis before our afternoon catch-up. It covers what was discussed with each client, what priorities shifted, what new items were created, and what technical context was applied.

The value is not just that Luis knows what tasks are assigned to him. It is that he understands the why behind them. He gets the context from meetings he was not in, the reasoning behind decisions, and the broader picture of what is happening across all our client work. This is the same argument I make about revenue intelligence: the richest data is in the conversations, not in the CRM fields. Meeting transcripts carry more signal than a lifecycle stage ever will. The same is true here. The real context is in what was said in the meeting, not in the task title in ClickUp.

We still meet every afternoon to discuss priorities and talk through anything that needs a proper conversation. But the baseline information transfer happens before we sit down, which means we spend that time on decisions rather than on catching each other up.

Documentation: The Thing I Hate Most

I will be upfront about this: documentation is the first thing I drop when things get busy. I know it matters. I tell clients it matters. And then I skip it because there is always something more urgent.

This is where Claude building directly into Miro and ClickUp Docs is starting to change things. Conversations about architecture decisions, process designs, and client strategies can be captured and structured into documentation without someone sitting down to write it up after the fact.

I say "starting to" because the raw output is not client-ready. The Miro boards Claude generates are better than anything I would produce myself, but Luis will be the one who takes those bones and designs them into something that is actively useful for clients. So far he has been building all of our workflows and diagrams without the Claude output, so adding an automated first draft into his process should speed things up considerably. But the bones are there: the architecture decisions, the process flows, the rationale for why we built something a particular way. That is the part that usually gets lost, and having it captured automatically, even in an ugly format, is better than not having it at all.

As this develops further, it should take a significant amount of documentation work off Luis' plate as well. That is the direction we are heading, and each iteration gets the output a bit closer to something that does not need a manual polish.

What I Am Learning

The biggest takeaway so far is that the value is not in any single automation. It is in what happens when you start combining data sources.

Meeting transcripts on their own are useful. Email threads on their own are useful. ClickUp task history on its own is useful. But when you layer meeting context with email threads with task data with Cowork session history, you start to build something that has a genuine understanding of what is happening across a client relationship.

I am thinking constantly about what other sources I can pull in and how to combine them. What happens when meeting insights from Fathom feed into the daily digest alongside email context from the nightly scan? What patterns emerge when you can see everything a client has mentioned across every channel? How do you use that compounding context to make better strategic decisions rather than just better task lists?

The layering is the key point. Each source adds a dimension. Each combination creates something more useful than the sum of its parts. And every week I am adding another layer, refining another skill, finding another way to connect the data.

The iteration is constant and it has to be. Every skill goes through multiple versions. Some work well from the start. Some need three or four rounds of testing before they are reliable. The experimentation is the point. You build, observe, adjust, and build again.

Where This Is Going

Not everything works perfectly yet, but the jumps I have seen in just a few weeks of building are massive. Each iteration makes a noticeable difference, and the pace of improvement is faster than I expected. Some automations are still too sensitive. Some miss things a human would catch. The documentation output needs work. There are entire categories of information I have not figured out how to capture yet. But the trajectory is clear and the progress so far has been genuinely impressive.

The system is getting more useful every week. The context it captures is getting richer. The connections between data sources are getting more meaningful. And the time it frees up is real, not theoretical.

What excites me most is the compounding effect. Each new data source makes every existing automation more valuable because there is more context to work with. The meeting intelligence improves the daily digest. The email triage feeds the task context. The documentation captures decisions that inform future strategy. It all builds on itself.

Why This Matters for Our Clients

This is not just an internal experiment. How we run GTM Layer directly shapes how we think about client work.

The system we are building gives us more context on every client relationship, faster response to things that get mentioned in passing, and the ability to pick up on ideas and problems that would otherwise get lost between meetings. It makes our strategy better because we are not relying on memory or scattered notes. We are working from a connected picture of everything that has been said, asked, and discussed.

The systems-thinking behind it is the same approach we bring to revenue architecture. Capture the signals. Enrich them with context. Route them to the right place. Make the data work harder than the people.

That is what working with GTM Layer looks like. We are building, experimenting, and refining, applying the same data-driven, intelligence-led approach to our own operations that we bring to every client engagement. The tools keep getting better because we keep pushing them.