I built two AI sales agents that share one attribution layer, and before I let either of them touch a real inbox, I ran them cold against a test dataset built specifically to catch the failure mode I was most worried about, the one I'd have been embarrassed to find after launch instead of before it.
The Agentic GTM Stack is InboxCopilot and EnrichmentMessenger, one shared attribution layer underneath both. Every action either agent takes gets logged as a touchpoint tied to a lead, and every touchpoint gets a capped, conservative slice of revenue credit: 50 percent ceiling, hard cap, written into the schema itself so no code path can quietly raise it later. The schema is plumbing. The reason the plumbing exists is the actual product. I did not want to ship an agent that could claim credit for something it did not do.
So the cold run was testing something narrower than whether the agents worked. It was testing whether the attribution layer would catch them when they didn't.
InboxCopilot passed clean, 3 for 3. EnrichmentMessenger did not. First pass came back 2 out of 3, and the failure was the kind I'd been dreading since I started writing the schema: a lead with no real work product behind it (null message, empty enrichment, nothing an agent had actually done) still got a disposition of created. That disposition is the one that emits a touchpoint. A phantom-sourced lead, credited like a real one.
Finding the actual defect
My first assumption was a model problem, the agent hallucinating a result it never produced. That would have been the easy story to tell and the wrong one. The real cause was step order.
EnrichmentMessenger's disposition logic ran a match-first read: check whether the incoming record matched an existing pattern, assign a disposition based on that match, and only after assigning it, check whether there was any actual basis for the match at all. On the lead that failed, the match-first branch fired, assigned created, and the no-basis check that should have caught the empty enrichment never got a chance to run, because by the time it would have executed, the disposition was already written.
It is a boring bug in the sense that boring bugs are the ones that actually ship. Nothing exotic. Just a conditional that checked things in the wrong order, in the one part of the system where order was the whole point.
The fix
Version 1.1 rewrote the disposition decision as a single ordered tree instead of a set of independent checks, with the no-basis check running first, before anything else gets evaluated. If there is no real basis for the lead (no message, no enrichment, nothing to point to), the disposition resolves to skipped_no_basis and the touchpoint never gets written. Zero credit, because there was nothing to credit.
Re-verification: EnrichmentMessenger 3 for 3. The exact record that failed the first pass now resolves correctly: skipped_no_basis, zero touchpoints. Combined across both agents, 6 for 6, no regression on InboxCopilot. The production substrate's full assertion suite runs 21 for 21.
What I'd do differently
I would have written the no-basis check first the first time, obviously, if I'd seen the failure mode coming. What I'd actually change is earlier than that. I'd design every disposition path as an ordered tree from the start instead of a set of independent checks that happen to run in whatever order the code lists them. Independent checks feel modular while you're writing them. They stop being modular the moment one of the things you're checking is "did anything real happen here," because that question has to come before every other question, every time, or it doesn't mean anything. Attribution systems earn trust in exactly one direction, and a single phantom credit on day one would have spent all of it.
The commits, if you want to look: af7ec15 for the point the repo reached shippable v1 shape, 5d58f51 for the Phase 4 close where the docs finally matched what the code actually did.
What's not in this post
You will find no traction numbers, revenue numbers, or customer counts here, because none exist yet. The Agentic GTM Stack launched without a single case study, on purpose, because the entire pitch is that it does not claim credit it cannot back up, and the fastest way to violate that on day one would have been to publish a made-up "early results" number. The first proof this product gets to point to is its own attribution data, running live on a public dashboard, filling in as real usage happens instead of being backfilled to look good on launch day.
If you want the deeper technical writeup on how the attribution layer itself is structured, that lives at stack.chadtdyar.com/deep-dive. The kit itself is at stack.chadtdyar.com, one-time purchase, self-deploy.
Top comments (0)