AI agents & custom software

Agents are only as good as what they read

An agent doesn't have judgment. It has inputs. Point one at a clean, complete, scored dataset and it does a junior analyst's work at volume without complaint. Point the same agent at a half-covered database full of records that decayed 30% over the past year and it produces confident, well-formatted, wrong output — faster and at greater scale than a person ever could.

This is why we treat data work and agent work as one engagement rather than two. The sourcing, enrichment, and scoring underneath an agent is not preparation for the interesting part; it is most of what determines whether the agent is useful. Teams that skip it end up with an impressive demo and a system nobody trusts by month three.

It's also why we build agents to say they don't know. An agent that returns a confidence signal and an empty field when the evidence isn't there is worth far more than one that fills every cell. Silent fabrication is the single most expensive failure mode in this category, because it is invisible until a rep quotes it on a call.

One agent, one job

We don't build a general-purpose assistant for your go-to-market team. We build narrow agents that each do a single, well-defined job, because narrow jobs can be specified, tested, and audited — and turned off individually when one starts drifting.

Account research is the most common: given a company, gather the specific attributes your ICP turns on, cite where each one came from, and flag anything it couldn't verify. Enrichment on a schedule is another, re-checking the fields most likely to have gone stale rather than re-buying whole records. Then there's routing and territory assignment, deduplication and entity resolution, CRM hygiene, and the quiet automations that move data between the tools your team already pays for.

Each one gets the same treatment: a written spec of what it does and what it must never do, evaluation against examples your team has judged by hand, logging of every input and output, and a kill switch. That's less exciting than an autonomous everything-agent, and considerably more likely to still be running in a year.

• Account and contact research at volume, with sources cited
• Scheduled re-enrichment targeted at the fields that decay fastest
• Routing, deduplication, and entity resolution
• CRM hygiene and cross-tool automations
• Custom internal software where no tool fits the motion

Where a human stays in the loop

The augment-versus-replace gap in the research — roughly 2.8× more pipeline for teams that augment — matches what the work actually looks like. The tasks that automate well are the ones with a checkable answer: does this company hold this license, how many locations does it operate, which of these two records is the same company. The tasks that don't are the ones requiring a judgment call about a specific human being.

So we draw the line at judgment and at anything customer-facing. An agent can assemble the research, propose the score, and flag the account. A person decides what to do about it. That boundary is also where our pre-outreach rule lands: nothing we build sends anything to your prospects. Your reps own every conversation.

In practice this means every agent has a review surface. Low-confidence results queue for a person instead of writing through. Bulk changes to the CRM get a dry run before they get an apply. And when an agent's output disagrees with a rep's read, that disagreement is logged, because it's the most useful training signal in the system.

Built into your stack, not beside it

We build in the tools you already run — your CRM, your warehouse, your workflow tools, your cloud account. No new platform to adopt, no separate login for your team, no data leaving your environment to sit in ours.

That constraint shapes the engineering. Scores and enriched fields are written back as first-class CRM fields with clear naming, so reporting and routing can use them. Jobs run on your infrastructure or against your credentials. Every automated write is attributable, so when someone asks why a record changed, there's an answer. And because it's all in your systems, the work survives us: if the engagement ends, the pipelines keep running and your team can read them.

How a build actually runs

We start by watching the work. Before writing anything, we sit with the people who currently do the task by hand and document what they check, in what order, and what makes them stop and think. That transcript becomes the spec, and it usually reveals that the real job is narrower and more particular than the request suggested.

Then we build the smallest version that produces a usable result, run it beside the humans on real records, and compare. Disagreements get triaged: some are agent errors, some are spec gaps, and a surprising share are cases where the humans disagreed with each other. Only once it's holding up does it get scheduled and wired into the CRM.

After that the job is operations. We monitor for drift, watch cost per run, keep the evaluation set current as the market moves, and retire agents that have stopped earning their keep. Building the thing is a few weeks; keeping it correct is the ongoing work, and it's the part most teams underestimate.

When not to build this

If an off-the-shelf tool does the job, buy it. We are not interested in rebuilding a CRM feature or a workflow product that already exists and is maintained by someone else. Custom is for the shape of your motion that no vendor has bothered to support.

If the underlying data is thin, fix that first — an agent on top of a half-covered database multiplies the gap rather than filling it. If the process changes every few weeks and nobody can say what the rule is, automating it just freezes the confusion in code. And if the task is genuinely a judgment call about a person, it should stay a judgment call.