I’m the founding AE at Dtwo. We built a security control plane for AI agents: it sits between agents and the systems they reach into, so a company can decide what those agents are actually allowed to do.
I’m also, as far as I can tell, our most demanding user. My entire sales job runs through my own Dtwo setup, with Claude Cowork on one side and Apollo, HubSpot, Google Workspace, Slack, and Granola on the other.
Nobody hired me for my YAML writing skills. I want to be clear about that up front. I am an account executive. However, in the last few weeks, I have wired new MCP servers into my setup, published versions and deployed them to production. I have also broken my own OAuth flow twice by regenerating an authorization link while I was in the middle of using it, which is the enterprise-software equivalent of locking your keys in the car while the engine is running. I mention this because the interesting part of this story is not that a salesperson can drive infrastructure. It is what happens when the infrastructure is the point.
The two things I built
A prospecting engine. I built it as a skill, which is a fancy way of saying I wrote down how I actually qualify accounts and then made it repeatable. It scores accounts against our real ICP model, weighted on the signals that have predicted deals for us, not on a generic firmographic filter. I describe what a good account looks like in plain English and get back ranked accounts with real people attached, pulled from Apollo, cross-checked against HubSpot so I am not cold-calling a company we are three conversations deep with.
The part I did not expect to matter most: it is bound to our approved messaging. Our claims live in a governed register where every claim carries an ID and a status: Proven, Supported, Aspirational, Do not use it externally. My outreach gets written against that register, so if a claim is not supported, I find out while I am drafting rather than after a prospect’s security team has fact-checked me on a call. For an early-stage company, where credibility is roughly the entire asset, that is not a convenience feature. That is risk management with a nicer interface.
An executive assistant agent. I built this one because I needed adult supervision. Giving my agents a boss, it turns out, meant giving myself one too. It sets my day. It checks my calendar, tells me what I am walking into and what I should know before I walk into it, sweeps my inbox for anything I let slide, and flags the deals that have gone quiet while I was busy feeling productive about the loud ones.
That last function is the one that has actually changed my behavior. Every AE has a version of the same failure: the deal you were sure about goes dark, and you do not notice for nine days because three other things were on fire. Having something that notices on day two, and says so before my first coffee, is worth more than any amount of activity tracking.
What a day looks like
Prospecting and enrichment collapse into one motion. When I find someone worth talking to, creating the account, the contact, and the deal in HubSpot is a conversation, not fifteen minutes of tab switching. Titles get corrected. Contacts get associated with the right company. Meetings get logged. My CRM is clean for the first time in my career, not because I became a better person, but because keeping it clean stopped being a separate chore I could postpone.
Call prep pulls from everything at once: HubSpot history, email threads, documents in Drive, meeting transcripts in Granola. Recently I needed to find what use case a university prospect originally wanted to test us with. It was not in the deal record. It was not in email. It was in a set of discovery call notes from months earlier that I had, in fairness to me, completely forgotten writing. One question, one answer, no archaeology.
Then there is the work that used to eat evenings. Scope documents with success criteria tied to procurement triggers. Buyer matrices. Call summaries to the team in Slack. Follow-up emails. These now get built while the context is still warm, and they land where the team already looks for them.
The part that is actually about Dtwo
I want to be precise here, because it would be easy to overclaim and I would rather not do that in a post about not overclaiming.
Most of the speed above comes from a capable agent connected to good systems. Plenty of people can get that.
What Dtwo provides is the thing that makes an organization willing to allow it.
Six systems connected directly means six separate connections, six consent screens, six permission models, and six places to look when somebody asks what the agent did last Tuesday. Through Dtwo it’s one control point. One place the tokens live, so my client never holds a credential. One audit surface across every system. One session to kill if something goes sideways.
It also makes possible a kind of rule that no individual application can express, because no individual application can see the others. A policy that says: once this session has touched customer data in the CRM, the tool that posts externally is off the table. HubSpot cannot see Slack. Slack cannot see Gmail. Only something sitting in the middle can.
I felt this concretely last week. Adding a meeting-notes server took one config change, and Dtwo registered itself with the provider and held the token. No application to create, no credential in my hands. The next server will be the same. Adding a Slack app, which uses older pre-registered credentials, required a human to go add a callback URL. That contrast is the whole argument in miniature: adding a tool should not mean adding a control surface.
What is next
I am running observe-only today. Dtwo sees everything and denies nothing, which is exactly how I would tell a customer to start. You cannot write a good policy for behavior you have not seen yet.
What I want next:
- An egress rule that redacts customer identifiers before anything leaves for an outbound channel.
- A cross-tool policy that blocks external posting after a session has read CRM data.
- Limits that let the agent read accounts freely but not quietly pull the entire book in a loop.
- My own activity log as the record of what I did, instead of reconstructing my quarter from six systems and a vague sense of having been busy.
None of that is hypothetical. It is the next configuration change.
Why this matters past my quota
I can tell a prospect what our product does. I would rather tell them what it does for me, every day, on real accounts, with real data, in the same architecture I am asking them to adopt.
Every security team I talk to asks a version of the same question: how do we let our people use this without losing track of what it is doing?
I do not answer that from a slide. I answer it from my own week, including the parts where I locked the keys in the car.
If you want to give your own agents a boss, start a free trial.