Srini Singarapu

Teaching agents to make a dollar

walk through the diagrams

i spent my summer at Phoebe, where i worked on our go-to-market engineering team. Phoebe builds ai agents for home-care agencies.

i wanted the whole path, from finding companies to catching bookings, to improve from each outcome. that takes an experimental mindset, plus systems that keep working when a model guesses wrong or a booking notification never arrives.

what is go-to-market?

Jeanne DeWitt Grosser, then Vercel’s coo, who built Stripe’s early sales team, got asked this question. go-to-market is any function that touches a customer or makes a dollar.

TAM, the total addressable market, tells you who could buy. icp, the ideal customer profile, tells you who fits. an mql meets marketing’s qualification criteria; an sql has been qualified for sales follow-up. cpl is cost per lead. cpql is cost per qualified lead. cac is customer acquisition cost. roas is revenue attributed to ads divided by ad spend. a cheap lead still has to become a useful conversation.

everything starts as an experiment

every launch needs a hypothesis, a success criterion, and a stop date. otherwise, spending continues because nobody agreed what failure looks like.

write a hypothesis, run a bounded test and judge qualified outcomes. scale with evidence, stop a failed test or wait when the data is inconclusive. record the result before the next hypothesis.

we recorded which tests earned more investment.

test what happened decision
video creative early cheap leads did not repeat stop that version
compliance keywords clicks without conversions stop
ads inside ChatGPT no demos in the test window stop
broad cold lists named account lists worked better narrow the audience
organic creative strong posts supplied the next paid tests repost, then test paid

an organic winner earns a paid experiment. it still has to prove it can produce qualified demand.

follow the lead upstream

work backward from a demo request: find the company, choose a reason to reach out, capture the response, then route it to the right person.

market evidence informs outreach and ads. calls, forms and replies become known companies, qualified leads and conversations. crm outcomes feed back to the market and the next campaign.

find the companies, then keep the evidence

we combined state licensing records, the npi registry, Google Maps through Serper, Care.com, Blitz, Clay, and Deepline. a company, its branches, and its employees need separate records. collapsing them into one domain loses the local buyer.

enrich in cost order: reuse evidence, pay to fill gaps, and keep the source.

public records, the open web and data providers supply evidence. normalize companies and branches, use existing records first, look up unresolved gaps, and review proposed updates with their sources.

some useful evidence is hiding in plain sight. a “caregiver login” link can reveal the software a business uses. that matters when product fit depends on an integration. the link is a clue to verify, not proof that every branch uses that system.

illustrative page-source excerpt. a caregiver login hyperlink points to a vendor subdomain. extract the vendor as a candidate, preserve the url, and verify before marking the integration confirmed.

refreshing records creates another problem: an agent can undo a correction someone just made. the protection belongs at the database boundary. preserve the corrected field, log the conflict, and let unrelated fields update.

human-override design. an agent proposes a phone and website update. a database trigger preserves a human-corrected phone while allowing the unrelated website field to refresh, and records the conflict.

find a reason to reach out

a job posting offers timing: someone is spending money to solve a problem. our scanner used hiring signals to find relevant companies and local decision-makers.

the difficult part was identity. a listing might sit under a parent brand while the buyer runs one branch. deduping on the brand’s domain suppresses distinct offices. resolve the employer and location before applying cooldowns or finding a contact.

start from a relevant hiring signal, resolve the employer and local office, then deduplicate by buying center. find a local decision-maker and validate contact details. preserve evidence or stop when identity is uncertain.

keep the conversation together

email and LinkedIn need the same account history, owner, and reply state. a reply should stop the other channel’s pending follow-up.

our operating document held the campaign rules. we tested paired approaches: a softer offer, such as sharing useful evidence, and a direct invitation to book. we called these mql and sql campaign variants; the copy itself does not qualify the recipient.

a simplified operating document defines the account owner, qualification criteria, campaign variants and stop rules. email and LinkedIn read shared history. a reply updates that history and stops pending follow-up across both channels.

give the ads agent a write boundary

the ads console supported reviewed changes, validation, and a fingerprint check that rejected changes if the account had moved since review. we built the Google Ads agent on top of those controls.

its objective is cost per qualified lead, using crm outcomes joined to the original click. the model writes a typed plan with evidence, an evaluation window, and a rollback. a critic challenges it. code decides whether to allow, request approval, or block it.

proposed ads agent architecture. Google Ads observations and crm qualified outcomes feed a planner and critic. a deterministic policy gate blocks forbidden operations or routes allowed ones to capped execution or human approval. only a validated executor can call the ads api.

sparse data can justify leaving the account alone. lessons and rejection reasons feed the next proposal; broader permissions require measured results and an explicit policy change.

proposed rollout by action type. start with read-only analysis, move to human-approved proposals, and allow capped execution only after measured results and an explicit policy change. regressions reduce permissions; prompt changes require replay tests and approval.

turn a response into a conversation

for a demo-line caller, Deepline resolves the number to a person and company, finds contact details, and validates the email. the icp model scores the collected evidence with tool calls disabled. that limits fresh invention; it does not make the score infallible.

the Slack card offers add or decline. add authorizes enrollment in the follow-up campaign. separately, callback requests become HubSpot tasks for a rep. speed-to-lead is the time between that request and a real response.

demo-line callers are enriched and scored, then reviewed through an add or decline Slack card. add enrolls the contact in an approved follow-up sequence. separately, a submitted callback request goes through core routing to a HubSpot task and a representative.

make missing bookings visible

we compared the replacement inbound path with the old path in shadow mode, field by field. that exposed bookings the old path had missed.

a poller also reads bookings from the source. webhooks, the source’s event notifications, and polling meet at the same durable ledger. booking identities and delivery claims prevent recovery from creating duplicate work. failures remain available for retry and inspection.

bookings arrive through webhooks or are recovered by polling the source. both paths normalize the booking identity and attempt an insert into a shared ledger. only a new record proceeds to dispatch. in shadow mode the new outputs are compared with the old outputs without live downstream effects.

once a conversation happens, its outcome belongs back in the system: which company qualified, which message got a reply, which ad produced a booking. that evidence changes the next list, the next campaign, and the next hypothesis.

how it works