The gaze of AI-energized VC is turning toward the worthy goal of building an agentic marketing stack, and the money is getting serious. Earlier this summer Gradial raised a 65 million dollar Series C, bringing its total raised to roughly 120 million. Then Ploy came out of stealth with a 27 million dollar seed founded by Bryant Chou, co-founder and founding CTO of Webflow. His pitch is the website as the hub of the whole growth system, optimizing itself and running campaigns in the background, continuously.

The thesis underneath these platforms is easy to agree with. A campaign that takes a week to imagine takes a quarter to ship, and then another quarter to run. Every page, email, ad, and iteration has to crawl through agencies, tickets, reviews, and tools built for a slower less integrated world. That bottleneck is still real for just about everyone.

We see this production-line problem every day when we meet new clients at Trelliswork and we are not working with giants like T-Mobile, Prudential, or AWS, all Gradial references BTW. Our clients, who range from 3 million to 550 million in revenue, have the identical problem just with a different scale. Linking all of these systems together to produce and run a campaign gets ugly fast, especially when you have multiple agencies in play next to internal teams that are stretched thin or barely staffed.

These new platforms orchestrate a series of processes that mimic a traditional stack. They invoke specialized agents and tune the output against the inputs you give them and the signal that comes back. A rules engine encodes brand, accessibility, and governance. A design system gets applied by default. GEO work ships different angles automatically and watches for what lands. Ploy runs the same logic through the website, syncing copy, campaigns, and CRM data on its own. Executing this pattern consistently and at high quality has always been doable. You just needed an army of agencies and tooling on hand. And time. Lots of it.

Taste comes full circle

A once cool word in Silicon Valley circles, now generally avoided: Taste. Greg Brockman has referred to “taste” as a new core skill. Paul Graham says it gets more important, not less. Dan Pink told a room of art school graduates at their commencement that “taste” is their killer app. You make things, and you find the courage to say no. Kyle Lacy put it best in an essay: "You cannot buy taste. You cannot template it. You cannot prompt it into existence. When production gets cheap, conviction gets rare."

We agree with all of it. The argument is not whether taste matters. The argument is what it looks like once you actually run one of these systems.

"You cannot buy taste. You cannot template it. You cannot prompt it into existence. When production gets cheap, conviction gets rare." - Kyle Lacy

What it looks like in the trenches

We run a very similar setup at Trelliswork. Standard workflows, off-the-shelf tooling, MCP/API direct for everything, and skills upon skills. Functionally it is what Gradial built, except we did not need nine figures to get there, and we have been profitable since day one. A few first principles got us here, and we still hold them.

• Humans love to tinker and are never fully satisfied. Treat that as a feature. Aim it at the output as deliberate taste and the work gets sharper, and unique. It's the anti-AI slop factor.
• You cannot outrun or out-invest the innovation cycle from platforms like Gradial. Build on top of it, keep abstracting upward, and treat every part of your stack as always under review.
• DTC can run close to 100 percent lights out because it can focus on one tight segment. B2B tends to be less focused, has a lot more cooks in the kitchen and tends to need more hands. Know which one you are.

Ask anyone who has stood up one of these systems. On the surface it is incredible. Then the first output lands and it is 80 percent there. You tune it to 85. Then 91. Then 95. That last 5 percent is bias, subjectivity, taste. It stays hard to automate, and it is the part people notice. You also have completely different quality bars for different audiences, markets, and clients so the level of human tinkering with output can vary significantly.
‍

The hard part is where services will still thrive.

Full lights-out is not a near-term reality for most companies, for two reasons.

First, focus. You can preach ICP all day, but most teams are not focused enough, especially scrappy, opportunistic founders willing to try every angle. Point a machine at an unclear message and you get more of an unclear message, faster.

Second, the work itself. Connecting the systems, cleaning the data, encoding the brand, refining the automation, deciding what is good enough to ship. For a focused company that is a decent effort. For the mid-market it is a mountain. Most buyers forget that part in the demo.

Platform companies sell software, not the work, and the good ones say so out loud. Gradial's delivery partner is Perficient. Gradial describes that role as operationalizing the platform inside complex enterprise environments, designing the architecture, managing the change, and bringing vertical depth across healthcare, financial services, retail, and automotive. Perficient ran the platform on their own marketing operation before ever taking it to a client, so the delivery team knows it from the inside.

That is the right model. It is also the best description of our job I have read all year, written by somebody else, about a company far larger than ours. Someone has to operationalize the capability. At the top of the market that someone is Perficient. Below it, the list gets short fast.

That is a services job, and it is a hard one.

Integration of all the signals to continually optimize and reinforce makes for amazing vision, even better slideware. Enterprises have a lot of these signal sources either from an army of vendors or software stacks already in place. Mid-market has significantly less, and sub-midmarket virtually none. The effort to integrate or harness these signals to make the platform work will take serious work.

That gap is where managed services providers and agencies like Trelliswork thrive. The platform hands you an engine. Someone still has to wire it in, aim it, and adjust the output. This isn’t a defense, it’s just a realistic view from the trenches supporting clients who don’t have billion dollar marketing budgets.

Prepare to keep a human at the controls (at least one)

We love this space. We applaud the platforms because one day we will be integrating them for our clients. I will take the bet that even once the machine runs clean, there will always be a few operators at the controls injecting taste, and clients looking at the output saying nah, not good enough, try again. As they should.

‍

‍

Trelliswork wasn't the plan. Buying a business was.

Before we had a single client of our own, we spent months trying to buy a business we thought we could turn around. Roughly $25 million in revenue with Blue-chip enterprise clients. A book of business built over decades, a software asset that was dated but operational, and a list of operating problems that made it less attractive to larger buyers looking for a simple tuck-in. On paper, exactly the kind of company we were looking for.

We got all the way to diligence. Multiple rounds with the management team, deep on the financials, learning the day-to-day.

What we found became the reason Trelliswork exists.

The business we almost bought

Good clients. Real margins. A platform that, while aging, still worked. Everything checked out, on paper.

Then we asked the one question that actually mattered. How does this business find and win customers?

The founders. They had built the entire book on their own relationships, and after years of carrying it they were ready to walk away. Nothing sat behind them. No marketing function, no repeatable way new business found its way in the door. A few people, a spreadsheet, and no plan for what happened when they stepped back.

We didn't read that as a reason to pass, we read it as the plan.  

Our plan was to fix exactly that

Our whole thesis for the deal was closing that one gap. We were going to install a modern GTM system and run it with focus and consistency, so new business no longer lived or died on a handful of relationships. Buy the company, build the engine, scale the model. That plan was the reason we wanted it.

The deal came apart over value. We couldn't line up with the seller on what the business was worth. That happens. The plan survived it.

The pattern was everywhere

Once we saw it clearly in that deal, we couldn't stop seeing it everywhere else.

Founder-led businesses, mid-market businesses, even smaller enterprises tend to look the same under the hood. Real expertise, loyal clients, real revenue, and a growth engine that begins and ends with a founder, or a trusted few. It isn't a flaw specific to distressed companies or bad operators. It's what happens when you build a business the way most people build one. You sell it yourself because you're good at it, and you never stop, because nothing else is in place to take over.

We've seen it from the other side of the table since, helping a private equity client evaluate an acquisition target of their own. We walked them away from that deal for the same reason.  
‍

That gap doesn't only cap how fast a business grows. It caps what the business is worth, and eventually, whether anyone will buy it at all. No acquirer wants to pay for a business that will crumble when the key rainmakers leave.

So we built the thing we couldn't buy

We didn't go find another acquisition target. We took the system we designed to turn that one business around and offered it as a service, to companies carrying more GTM work than their team can execute.

That system became Trelliswork built around what we call the 10/80/10 model. You own the first 10%, the strategy and the calls only you can make. We run the 80% in the middle, the production and the execution. You own the last 10%, review and approval.

‍

Then we started delivering

The work taught us things we couldn't see from the outside.

We built Trelliswork for founder-led businesses first, the ones with all the right ideas and nobody behind them to execute. Running the model pulled us into the mid-market, and then further up, into companies with real budgets and real teams that still move slower than they should. The system doesn't get less useful as a company grows. It gets more useful.

Delivering the work also changed how we think a services firm should be built. That's its own piece, and we'll write it.

If your GTM has to move faster than your team can

That's the constraint we built for. Trelliswork is the GTM execution partner for B2B companies between $50 million and $500 million in revenue whose marketing has to move faster than the team allows. We bring the GTM system and get going in days, versus most large agencies that take three to four months to onboard.

‍

Being lazy just got harder

That is a good thing. Becuase AI slop is out of control.

Don't believe me? Open LinkedIn and scroll five posts.

Four of them are 100% AI.

Claude's text now carries a watermark you can't see. Anthropic built it on SynthID, a technique Google DeepMind published in 2024, and it costs nothing in writing quality. Copy the text into another document, another platform, another email, and the mark usually survives the trip. It doesn't say who used Claude. It only says Claude was involved. Anthropic is also shipping a way to check: run any piece of text against the Claude API and get back the odds that Claude wrote it.

Until now, the main way to catch AI writing was to spot the tells: the tics, the rhythm, the phrasing that gives it away. That method is crude, and it doesn't scale across platforms. LinkedIn already has an "AI slop" button people can hit to flag a post, and every flag trains its detection model a little more. A watermark changes the game. Platforms no longer have to guess from style. They can check directly, gain greater confidence in their detection accuracy, and take direct action.

Here's the full rundown on the watermarking approach from Anthropic.

Here's where we'll feel it

Content rankings will start to move first.

LinkedIn, Google, Reddit, and others will start testing what happens when they quietly down-rank content that keeps tripping the watermark. Posts and pages that read as more human climb instead.

Inboxes come next.

Spam filters already weigh dozens of signals, and AI-content detection is a natural one to add. A team running the same lightly-touched AI sequence across a thousand contacts could watch its deliverability quietly slide, with no idea the watermark is why.

Then it gets personal for agencies.

Once a client can run the check themselves, they will. "Was this written by AI?" stops being a hypothetical and starts being a question in a kickoff call or an end of week summary report. A team with a real editing process answers it without flinching. A team without one starts explaining itself.

None of that is really about the technology. It's about who gets rewarded. The teams doing the harder work, using AI but still holding the bar high, become worth more over time than the teams pumping out raw model output and hoping nobody checks.

That's the standard to strive for. Every piece has to solve a real problem, and every piece has to carry an actual human team's opinion, not a smoothed-out average of one. Expertise and trust don't come from anywhere else. My personal hope for where we're at? As detection gets better, that gap should only widen, and human-led work should start winning again.

Raising the bar

We're optimistic about where this goes: An internet that isn't drowning in unoriginal, interchangeable AI text. One where a person's actual ideas carry more weight than they have in years, once you can finally hear them over the noise.

Here's the comparison I keep coming back to: DeepMind's advances in Go a few years ago. Move 37 didn't just prove the AI could win. It made every human still playing the game better. That's the shape of what's coming for marketing content. The human-made kind most of all.

And this isn't a mutiny on all things AI, to be clear. We use AI every single day in the work we do for clients. Our clients expect it. The difference is whether your agency is bringing anything to the table 'besides' the easy button. Our approach is anchored in our 10-80-10 model, which you can read about here.

It's easy to generate slop.

It's harder to think critically, solve problems, expand your perspective, have an opinion, review with a client, improve the position, create a supporting visual, on brand, ship to production, and wake up and do it all again.

What's the call to action? Save the internet. Don't be lazy.

Do the hard work.

Most teams adopting AI for delivery are optimizing for one thing: speed of adoption. Pick a tool, build it into your workflows, and move. It feels fast because you are moving fast. But nobody stops to ask the harder question. What happens when a tool in your new workflow doesn't show up for work?

Or worse: what if the platform you run those tools on is just having a bad day and calls in sick?

We found out yesterday.  

Claude is our primary work surface. We run most of our client delivery through it, both Claude Cowork and Claude Code, and it has done a lot to make a messy pile of client workflows feel like one place to work. Then, on a heavy delivery day when we needed Claude to show up, our team got the ominous service outage notice.

‍

Claude was down. And this time, it felt like half our company didn't show up for work.

If you use Claude as often as we do, you know outages aren't uncommon. To their credit, they are shipping at a crazy pace, and it would be even wilder if there was never a disruption! But as we scale the codebase our delivery system runs on, those outages hit harder. We rely on the platform more every month, and that reliance has created a new risk surface.

For an AI-native business like ours, a single work surface like Claude is now, besides our people, the most consequential operational risk we carry.

The real cost isn't downtime. The cost is going backward.

When people picture an AI outage, they picture work stopping. In real life, and as an agency operating in this mode everyday, you don't stop; you fall back to the old way of working.

Once you’ve run at the pace these tools allow, the old way is genuinely painful. The whitepaper that took a morning is back to a week of copy-paste and formatting. The ICP you would normally call up in seconds turns into a hunt through Google Drive. The article you would have shipped by lunch waits. Your clients' expectations don't reset because your tool had a bad day. The turnaround they now count on was set by the fast version of you, and on the slow morning you still owe it. That gap between the speed you built the business around and the speed you can hit without your stack is the cost. You feel it in every deliverable that used to be quick.

And the exposure runs deeper than the tool you work in. There are two layers here, and most teams have a backup for neither.

The first layer is the harness, the surface you actually do the work in (think Claude Cowork, chatGPT, etc). The second is the connectors, the pipes into the systems where the work lands. Webflow. Granola. HubSpot. Your CMS and CRM. Those connectors are not resilient in themselves, and they’re constantly changing. This morning, Webflow would not connect from Claude Cowork at all, while it worked fine from Claude Code and from every other AI tool we tried. Same company, same login, one path broken and the rest fine. A connector failure drops you back to the old way just as fast as a harness failure. You are only as portable as your weakest layer.

How we got back up in fifteen minutes

We recovered fast, and not by luck. We recovered because of how the stack was built.

Everything we do is a skill. A skill is a markdown file with instructions, a saved recipe the AI follows. Brand voice, ideal customer profile, whitepaper generation, each one is its own file. Those skills are grouped by client into plugins. The plugins live in a marketplace, and the whole thing is managed in code in GitHub. Our delivery stack is, in effect, a codebase. It is built on an open standard for defining a skill, not on anything proprietary to a single vendor.

That one design choice is what saved the morning. Because the stack was code and the format was open, we pointed it at a different engine. We took the same GitHub repository into Grok, then into Codex, launched it from the same folder the same way we would in Cowork, and ran the same client skills. There was some translation to get another engine to read a stack we had first shaped for Claude, but the assets themselves moved cleanly. From dark to running took about fifteen minutes.

The swap was natural because we were already multi-tool by choice, not just in a crisis. Claude is home base, but we run Grok and Codex for the workflows they handle better. Different engines are genuinely better at different jobs, so we already reached for the right one per task. The outage just proved that the same portability we used for fit, we could use for survival.

Think portable, single sources of truth

The reason the move worked is not the specific tools. It is that we treat marketing delivery the way an engineer treats a codebase, and one principle carries most of the weight. A single source of truth.

In our world, that means every process, standard, and reference we reuse lives in exactly one place, as a skill. A skill packages the knowledge of a workflow, a brand standard, a data mapping, or a template, with its own inputs and outputs. When a delivery surface needs that knowledge, it references the skill. It does not copy it.

That one rule shuts down the two failures that turn AI adoption into chaos. The first is replication: a dozen versions of the same messaging framework scattered across delivery folders, each drifting a little further from the last, and a token tax paid every time someone hunts for the right file. The second is reinvention: two people rebuilding the same ICP or the same whitepaper process from scratch because neither knew the other had already done it. Single-sourced skills remove both. Improve the skill once and every workflow that calls it improves with it.

The payoff is composability. Skills stack into plugins, plugins are organized by client account, and a workflow gets assembled from single-sourced parts instead of rebuilt by hand. That is what lets us run our execution engine as code. It is also the difference between a pile of disconnected Claude chats each improvising and one organized, efficient, AI-native delivery motion.

Here is what that looks like in practice. Take an ideal customer profile. One approach is to write it up, save the document in the client's delivery folder in Google Drive, and move on. It works until you try to use it. Now someone has to remember where it lives, point the AI at it, and spend tokens loading it every single time. Worse, if your work is scoped to a subfolder, the tool may never look up the tree to find it at all. The ICP is right there and still out of reach.

The better version is to promote that finished ICP into a skill. Once it is a skill, it behaves like an imported library. You call it from anywhere, it loads on demand, and it reads the same every time. That is the difference between a filing cabinet and a system. It is the same property that let us move our entire stack into a new engine overnight. The ICP-as-skill and the fifteen-minute recovery are the same principle at two sizes.

Thinking like an engineer inside a marketing team is what pays off here. Same discipline, applied to a different kind of output.

Your over-reliance on Claude risk won’t go away on its own

It is tempting to treat all of this as temporary. Pick whichever model is winning, wait for it to pull ahead for good, and skip the hassle of staying portable. That bet misreads the moment.

We are not heading into a winner-takes-all world where one model rules them all. The lead changes every few months. The engine that is best at long reasoning today gets passed on coding next quarter, then leapfrogged again. That is exactly why we already run Claude, Grok, and Codex side by side, each for what it does best. Betting your delivery on one model winning permanently is betting against the one thing you can count on right now, which is that things keep changing.

And here is the part that holds even if you disagree. Say one model did win outright and stayed ahead. You still would not want your whole company wired to a single vendor's uptime, pricing, and roadmap. Over-dependency is a weak position even when the thing you depend on is excellent. Great today does not owe you great, available, and affordable tomorrow.

Change is constant right now. That makes a backup plan cheap insurance, and it makes skipping one an expensive mistake to get wrong, because the alternative when it breaks is the painful, slow way of working you already left behind.

What it costs to skip this

If you don't build this way, you are one bad morning away from being dragged back to the old pace. And the trigger is not yours to pull. It belongs to a vendor.

You will have rebuilt your business around a speed you cannot reliably hit. Every asset trapped in one tool or buried in a folder is a dependency you cannot see until it snaps you backward. Teams that skip this keep reinventing the same deliverables, and they keep getting surprised when a company they don't own decides how fast they get to move that week.

Redundancy here is not overhead. It is what protects the pace your client promises now depend on.

Oh, and just in case you need this later: https://status.claude.com/

‍

Earlier this month Chris and I got to spend time with a graduate-level marketing class at the University of Washington. It was a fun group, and the goal was simple: give them an honest look at what day-to-day marketing actually feels like inside a GTM agency like Trelliswork, and where the work seems to be heading. We talked through how much has shifted, and we kept circling back to one idea that matters more now than at any point in our careers: the way you learn marketing has to change too.

Here is what we walked through.

Marketing has changed

The fundamentals still hold. Know your audience, tell a clear story, earn attention. But the surface area of the job is bigger now. A marketer touches data pipelines, automation, AI tools, and code on a normal Tuesday. The role looks less like a campaign planner and more like a combination of builder and air traffic controller, making the thing and directing everything moving around it.

It's more technical than ever

You no longer hand off the technical work and wait. The people producing the best output are the ones who can open a terminal, wire up a tool, and ship the thing themselves. Comfort with technical work is becoming the difference between a good marketer and a stuck one.

You have to jump in headfirst

You don't learn this from a syllabus. You learn it by staying curious, trying new tools and approaches before you feel ready, and looking for better ways to work along the way. The students who get ahead will be the ones who stop waiting for permission and start experimenting.

Everyone is relearning

Everyone is learning the new tools at the same time, so on the technical side the gap between a student and a veteran is smaller than it has ever been. But experience matters more than ever. Judgment, taste, and knowing what good looks like are valued above anything else, because the tools change but the ability to point them at the right problem does not. That is the opportunity: pair fast learning with real judgment and you become hard to replace.

Think in code

Code is becoming the medium for now, not just the back end. I say for now because coding may not stay as important as it is today. But in this moment, code gives you more control over the models than any other interface. When you can describe what you want and build it directly, you skip the handoffs, the misread mockups, and the version sprawl. It also lets you get to discrete points in the creative process, returning to any version or branching from it instead of working off one file that keeps changing under you. You stop decorating slides and start shipping work.

The tools have all changed

The stack you learn on today will not be the stack you used a few years ago, because most of it did not exist yet. Claude, RB2B, Granola, Clay, Gemini, Riverside. These tools enable more than 80% of the work we deliver for clients, and none of them existed five years ago. Learning a fixed set of tools is no longer the goal. Learning how to pick up new ones fast is. We evaluate new tools on an almost daily basis. The only real choice is to keep adapting and evolving. And to be fair, it is exhausting trying to keep up.

What this looks like in practice

To make it concrete, we showed the class three whitepapers we built for three different clients. Every one was created and published entirely in code, from a terminal. No design tool, no page editor, no dragging pixels around a canvas.

The point was not that the work built itself. It was that we got to rethink the whole process. When the document lives in code, a round of feedback is a change in the source, not a manual rebuild. A revision that used to mean a designer, an export, and a reformat became a single pass. So the cycle time went from days or weeks to minutes.

That is the shift. Not a faster version of the old process, but a different process altogether.

The takeaway

Marketing rewards people who build. If you are early in your career, that is good news. The tools are new enough that effort and curiosity can outpace tenure, but the point is not to beat experience. It is to gain it faster. Curiosity is the bridge. It lets you take on real work sooner, see more reps, and build judgment years ahead of schedule, and experience will always be what matters. Open the terminal, make something, learn from it, and do it again.

‍