Our first system took 1,200 target accounts down to 48. We think 48 may still be too many.
Most AI GTM today looks something like:
Find a list > enrich it > prompt an LLM > send an email > update the CRM.
Useful. But it’s still mostly campaign automation.
We’ve been working on something broader at Dtwo.
The question we started with was:
What would our GTM operation look like if agents could actually do work across the stack?
Not one AI SDR sitting on top of Apollo or Clay.
The whole operating system.
The system should be able to answer:
- Why this account?
- Why now?
- What do we already know?
- Who matters?
- What should happen next?
- Did it work?
Once we started building around those questions, the architecture became pretty clear.
Research was being repeated, so we needed memory.
The same capabilities kept showing up, so we turned them into skills.
Different events needed different sequences of work, so we needed workflows.
The agents started interacting with real systems and data, so we needed policy.
And if the system was going to get better, outcomes needed to feed back into it.
At a high level:
Sources > context > memory > skills > workflows > policy > actions > outcomes > learning.
A useful distinction:
Sources tell us what happened.
Apollo, HubSpot, Google Drive, email, product activity, the web.
Context tells the system how we think.
ICP, personas, positioning, qualification rules, signal definitions.
Memory tells it what we already know.
Previous conversations, people, objections, product usage, relationships and commitments.
Skills define what the system can do. Workflows determine when those skills run and in what order.
In outbound, that might mean finding an account with a real signal, pulling what we already know, identifying the right person and drafting a message.
Policy tells the agent what it can and can’t do.
An agent can have access to customer documents, the CRM and email but that doesn’t mean it should rewrite your pipeline or send messages you never approved.
That is where Dtwo sits in our own architecture.
The GTM system can decide what should happen next.
Dtwo governs whether and how that action is allowed to happen.
We keep the AI tools and MCPs we already use and add Dtwo policies in natural language. We got our first governed workflow running in under 15 minutes.
The goal isn’t to take humans out of GTM.
It’s to let agents handle more of the research, reasoning and execution we can verify, while keeping human judgment where it actually matters.
We’re starting with outbound because it gives us a very concrete problem to solve.
We ran roughly 1,200 Apollo accounts through the first version of the system.
It narrowed them to 48 worth deeper attention.
At first, narrowing 1,200 accounts to 48 sounded aggressive.
Then I thought: 48 may still be too many.
Because the goal isn’t to get AI to find more reasons to contact people.
The goal is to find the small number of accounts where we can actually answer:
Why this company?
Why now?
Why Dtwo?
Who matters?
What evidence supports it?
If we can’t answer those questions, the system should do something most AI SDR tools aren’t optimized to do: nothing.
The architecture is meant to extend well beyond outbound: account research, prospecting, meeting prep, partner development, lifecycle, content, reporting and product-led sales.
We’re explicitly building it with product-led sales in mind too.
Eventually, product activity should contribute to the same account context as outbound and sales activity not just who signed up, but who governed a real agent action, came back, connected more systems or started behaving like a production deployment.
The question then becomes less:
Who should sales contact?
and more:
What is happening across this account, and what should happen next?
We’ll publish the repo shortly.
It includes the first skills, workflows, customer-memory model and policy architecture we’re using to build this.
Next: why we stopped thinking about this as an AI SDR.
Want to see how Dtwo works with your agents? Start a free trial.