How Gradial Is Automating the Unsexy 95% of Marketing With Deip Kumar

• Content generation was never the bottleneck. At one Fortune 500 customer, copywriting took two days out of a six-week campaign. The other five weeks were execution.

• Writing safely into 20-year-old enterprise software is the harder engineering problem, and rollback, audit, and governance are the actual product.

• The teams that win will not be the ones that cut costs the most. They will be the ones who run 10 times as many experiments once execution becomes cheap.

Let's dive in. No floaties needed…

Revenge of the Nerds

Deip Kumar, Co-Founder and CTO of Gradial

Deip Kumar spent his SpaceX years as lead software engineer on Starlink's phased arrays, the flat-panel antennas carrying every byte of traffic between users and satellites.

In early 2023, he left to start Gradial with three Dartmouth friends, including CEO Doug Tallmadge, who had been running Starlink's satellite and network simulation.

Gradial builds AI agents that execute enterprise marketing operations inside the systems companies already run, Adobe Experience Manager, Salesforce, Jira, and Workfront, rather than generating the creative work on top of them. The company now has over 100 people and works with over 15% of the Fortune 500, including T-Mobile, AWS, Prudential, and U.S. Bank. In June, it raised a $65M Series C led by Insight Partners at a $675M valuation, bringing total funding past $120M.

What makes Gradial interesting is where it chose not to compete. While the market piled into content generation, Kumar's team went into the plumbing, and the numbers they reported are the argument for that bet. In a T-Mobile pilot, a campaign measured at 1,000 to 1,200 cumulative hours was re-run in 80 hours, most of it human review, with a T-Mobile senior director publicly crediting an 80% or better cut in time to market.

The tension in the story is that the work is genuinely thankless. Building a true two-way sync engine into a Java Content Repository so an agent can safely edit a Fortune 500 homepage and then unwind exactly what it did is not the kind of thing that trends. It is, Kumar argues, the only reason any of it can be trusted to run.

So, what does Gradial actually do?

Gradial builds agents for the part of marketing nobody really sees, which is the operations. Most people have visibility into the creative elements, the content generation. But under the hood, every enterprise marketing team is running on an extensive stack. Adobe Experience Manager for your CMS, Salesforce or Marketo for email campaigns, Jira or Workfront for ticketing to manage your queue of work and your work graph.

Our agents work inside all of those systems the way any employee might, through the real APIs and the authoring interfaces, and then they do the work itself. Build the web page, run the QA, update the campaign settings, close the tickets in Jira, all with human approval gates on everything that goes live to the public.

We started in early 2023, the four of us founders, great friends from college. Doug and I also worked at SpaceX together. He was on Starlink's network simulation, answering questions like where should we put satellites, in which orbits, how many do we need. I led software on the phased arrays, the main antenna systems on both the user terminal and the satellites, serving all the internet traffic to and from users. Our other two co-founders came from Microsoft AI and the investing world.

Today we have over 100 people, the vast majority in Seattle, we work with over 15% of the Fortune 500, and we just raised a $65M Series C led by Insight.

Why go after the backend instead of content generation?

Content generation was never really the bottleneck. When we dug into what it actually takes to launch a campaign, and why it takes six weeks, the copywriting was maybe two days. The other five plus weeks was all execution. Taking the brief and translating it into tickets for every discipline across the org, building the page in the CMS, resizing assets for that template, localizing content, producing variants for different audiences, the QA and the legal and brand and accessibility review, all the approval gates through the chain of command, then publishing at the right time.

Before we got into T-Mobile, during the pilot stage, they measured what their next campaign would take in total cumulative hours. It was around 1,000 to 1,200. Insane numbers. We re-ran that exact campaign with a reference of what the actual output was, and we did it 80% faster. The total went down to 80 hours, and most of that was work you already want to be human work. The QA, the approvals, the judgment and feedback you ultimately want there. So we went where the hours actually are versus where the hype might be.

It is also a much harder engineering problem, because you have to write safely into 20-year-old software systems, with all the auditing and revertibility, versus content generation where you are rendering text in a chat or an image. But that is why it is so valuable. We are not building the fun part; we are fixing the broken part.

Why does shared memory across AEM, Salesforce, & Jira matter?

In an enterprise, one fundamental problem is that you have the Jira workflow, the AEM workflow, and AEM is Adobe Experience Manager, a CMS, and then your own workflow in Salesforce for campaign management. They are all fragments of the same piece of work. They should represent the same brand, but each system has its own implementation and only sees a fragment of that workflow. It is the human coordinators who carry the connection, and that is really in their head.

So if an agent cannot carry that connection across all the systems, it has to start every task from zero, and you re-explain your company's context and your workflow in each system every single time.

The memory system stores that context, and ours is layered. It would not be honest to describe it as one big brain. There is live context, information about your org structure, so we know who to go to for an approval or asset selection. Who is the designer in your org? There are brand rules, your voice, the do's and don'ts. Then governance, accessibility requirements and that sort of thing. That is represented as almost a wiki the agent has access to, just like you may have Notion documenting all those things.

Then semantic memory, us embedding your content and asset library so an agent can find the right hero image or the right pages for a product you are trying to rename, instead of you handing it the explicit entities. And finally learned memory. For every run, a background process, also agentic, analyzes what worked, what did not, and what the user typed out that we may need later.

Maybe users always flag a certain thing in review, so we note that down for future agents to be proactive about. Or the org says banner for a component the developer named something else. All of that goes into durable memory future runs can leverage. That last one compounds. The more you use Gradial, the better the system gets, because it is building up institutional knowledge that was decentralized across your org, or really just in people's heads.

Why is two-way CMS sync so much harder than it sounds?

It does sound easy. It is somewhat well known in the engineering world that sync engines are tough to build, especially high performing ones with true two-way sync. A sync engine is taking a remote system and effectively replicating all of the data and behavior in a local copy. If you change the local copy, you sync it back up to the remote source of truth, and vice versa. Reading from a CMS is easy, but writing to one is hard.

Take Adobe Experience Manager. The content is not a document, not an HTML document, it is a tree structure in a Java Content Repository. Pages, content fragments, and assets each have different versioning behavior and different APIs backing them. There is also inheritance, which matters for localization. Touch one node on the base version of a page and you may silently change 12 pages that inherit from it, all the localized or audience variants.

And there is no uniform way to undo across those types. It is also a multiplayer system, so humans and agents are editing the same content simultaneously. We have to write safely while being able to revert our own work without undoing conflicting work people are doing outside of Gradial. So the sync system builds a versioning layer that captures every mutation we are about to make, and guarantees every edit is idempotent, so retries do not double apply or corrupt anything.

All our writes go through a single coordinator so everything is coherent. What you get is that you can tell the agent to revert everything it did, or one specific thing, and that is a first class operation, with understanding of the dependencies, merge conflicts, and drift. It sounds like overkill, but if you are giving an agent unlimited write access to a Fortune 500 homepage, you really do need those protections.

What architectural mistakes do enterprises keep making?

One is automating a step instead of the end-to-end workflow. Today you see a copilot in each individual tool, one for the CMS, one for the ticketing system, one for email. But you still deal with the handoff between them, and that is the fundamental limiter. Humans are still doing the coordination. The work never lives in one tool, so the automation has to span each of them. We focus hard on building the right primitives to represent a work graph across all these tools.

We take in how the customer describes the work, the briefs, the tickets, and represent it as a DAG in our database. The agent interacts with that DAG, so it sees the dependencies, the successors, the predecessors, and works toward the final node in the graph. This is what you see if you just use Claude or ChatGPT. You have individual threads but cannot connect them. Independent lines of work with no dependencies and no ultimate workflow to get to an outcome.

You also need durable execution. Some of our runs take 10 plus hours because agents are making dozens of judgment calls, there are dependencies everywhere, and sometimes you are waiting on human approval to move to the next step. So you need execution that runs over days or weeks, survives failures mid-work, guarantees retries are safe, and checkpoints. Many internal builds do not have that. It is one-off tasks, and you have to figure out the current state of the world and continue with a new thread.

Our agents have the graph, so they ramp up on current context and continue durably. The final one, not obvious but maybe the deepest, is automation with no undoability. If you cannot answer what exactly the agent changed, what humans changed, and how to get back to an earlier state, you do not have a full automation strategy. So rollback, audit, and governance are the actual product here.

Did anything from SpaceX transfer to Gradial?

It may not seem like it, the domains are so different. A phased array is thousands of small antenna elements on a flat panel about three feet in diameter, each one working with all the rest. It is a coordination problem, and the software coordinates it. The timing and phase shifting of each element, literally the phase the light comes out of each antenna. You need software partly because you cannot produce the hardware precisely to the micron level, so the XYZ coordinates are slightly off expectation and you correct that in software.

But even beyond the imprecision, beams are formed by multiple antennas contributing to each beam, and you have 16 simultaneous beams on each transmit antenna. So coordination is the central point where everything finally works. Before that you have many hardware elements not coordinating. In that abstract sense, that is the same way I think about Gradial. Those pieces are cheap and fallible without coordination between all the AI actions being made. The value is the orchestration layer that coordinates hundreds of actions by many agents, in the right order, against the right systems, toward one reliable outcome.

The other thing SpaceX drills into you, especially with satellites that can fall out of the sky, is failure scenarios. You cannot ship yourself to space to fix the antenna after launch. So the system has to detect its own faults, degrade gracefully, and recover. That paranoia I definitely brought over.

Everything about how we architected our agents, isolated sandboxes, the auditing with snapshots, the two-way sync so we have precise understanding of every mutation, full rollback designed in. I do not think this engineering problem has ever been treated like that, so that framing was an important transfer.

What were T-Mobile, AWS, & Prudential doing wrong?

Nothing broke. They are not doing anything wrong, which is almost the problem. It is hard to detect, because you are used to your workflows and how long things take. All of it technically worked. They hit their outcomes on some timeline and built their whole operations around those expectations. So they did not even envision a world where that bottleneck was 10x faster.

Take an example. A marketer wants to update pricing on a page. That becomes a ticket. It goes into a queue, gets triaged, gets assigned to an AEM developer, they build the pricing component, send it back for review, revision, approval, then brand and legal, and then you can schedule and publish. There are literally 10 plus people involved, and multiple weeks of elapsed time. For the specific campaign we A/B tested at T-Mobile, that was 1,000 cumulative hours. The same launch went down to 80 hours, and the 80 is mostly humans doing the judgment, giving feedback, iterating, approving, which is exactly what you want. The actual agent execution was probably an hour total. The senior director at T-Mobile, Nick Pappas, said publicly that we cut their operational time to get content live by 80% or more.

What does a marketing team look like in five to 10 years?

Much smaller in the middle, the execution and operational layer, and stronger and even larger at the creative and strategic edges. The layer that is not going to shrink is the creative person or the strategist. It is the coordination layer that shrinks, the ticket routing, figuring out the status of any work item, the handoff work. All of that exists because systems cannot talk to each other, and now Gradial agents absorb it. A good analogy is a newsroom, where people collaborate in person, decide what the brand should say and be, and the execution layer gets it live the same day. Your news story breaks and it is published within the day. That is the vision we want to bring to all digital experiences.

Bigger than headcount is the cultural shift. Right now marketers are limited by execution cost. They are used to two campaign slots per quarter. When executing a campaign becomes basically free, you stop rationing your ideas and start testing a lot more of them, and creatives are not thin on ideas. So the teams that win the most are not the ones that cut the most cost, they are the ones that run 10 times more of their experiments. Humans stay on craft and judgment, agents handle operations. The marketers who thrive are the ones who learn to direct agents the way editors direct writers in a newsroom. That is a skill worth building now.

What does the fundraise actually buy?

The biggest part of the plan is what we are calling ACI, agentic content infrastructure. Gradial today primarily integrates with existing systems, your CMS where your website already lives, the ticketing system you use, the analytics platform you use. ACI is that software stack built natively for agents. We are thinking from first principles about what the stack should look like when agents do all the operational work. It is a completely different design from anything out there, and really a collapse of the software.

You do not have as much application software and logic and algorithms. It is infrastructure for agents to operate on, sandboxes they can write code in and do their work in, plus the agent harness that deeply integrates with that infrastructure.

We are starting with the CMS, a way to build, develop, host, and serve your website without the software bloat. Today you pay a lot for legacy CMS systems, and you are really paying a tax. Every time you want your content you go through this external software system. With ACI you migrate content out of your existing CMS into raw cloud infrastructure, for example AWS S3 or Azure Blob Storage.

All your content lives in your own cloud and our agents operate it. You gain control and ownership, and you are no longer paying the software tax, because you do not need the software. The agents are building your website. You can redirect that money and time toward strategy, or personalization. We are starting with the CMS, but we are going to rethink the entire stack for building and operating digital experiences.

Quick Poll

Additional Reads

• Exclusive: Gradial raises $65M for agentic marketing, Axios

• Gradial raises $65M as startup sees rapid growth around agentic tools for enterprise marketing, GeekWire

• Doug Tallmadge, Co-Founder and CEO of Gradial, Interview Series, Unite.AI

Rate This Edition