01 · Company
Acme Robotics
- Domainacme-robotics.example
- Sourcemanual
- Statusnew → researching
Foldnine · autonomous sales pipeline
AI agents that discover, research, qualify and engage your next customers — reading the public record at a scale a person cannot, and stopping at a draft a person signs off.
The premise
A company that posted a Senior DevOps Engineer role sixty days ago and wrote about a Kubernetes migration last month has told you what it needs, when it needs it, and in its own words.
Systems rarely act on that, because reading it at scale is tedious rather than hard. That is the whole job Foldnine does. Everything else — the schema, the workflows, the approval queue — exists to make that judgement repeatable and to stop it turning into spam.
The pipeline
Six stages, each a scheduled job with its own contract and its own row in the database. Every stage is named for the workflow that runs it.
Candidate companies enter the pipeline and are deduplicated on domain. Until this job exists, companies are inserted by hand — the rest of the pipeline does not care where a row came from.
Six conventional paths on the company's own site, then the public
JSON of seven hiring boards. robots.txt is honoured
longest-match. A cheap local model triages; only survivors reach the
research model, which separates facts from inference and never
invents.
One hundred points across six components. The model proposes and the workflow enforces: three components are capped in code and the decision-maker score is replaced outright from the contact table. Absent evidence scores zero.
People come from the company's own pages and from public commit
metadata on its GitHub organisation. Every row carries a
source_url and a discovery_method, so
"where did you get my details" always has an answer. Blind guessing
is deliberately not implemented.
One hundred and twenty words at most, one concrete observation, one small ask. The greeting and signature are assembled in code, never written by the model. A draft that breaks a rule is stored with the reason, not quietly corrected.
Approval is a state in the database, not a setting in a config file.
No row reaches approved without a person, and a
suppressed address is rejected by a trigger before any workflow gets
a say.
Inbound mail is matched to its thread and classified into one of eight outcomes; questions and pricing route to a reply, anything that commits to a date or a contract routes to a person. The contract and the schema exist; the jobs that run them do not yet.
One company, end to end
A worked example, with invented inputs. Nothing here is a Foldnine customer and no number on this page is a production statistic.
01 · Company
Acme Robotics
02 · Signals found
03 · Score
92/100
HOT
04 · Contact
Sarah Mitchell
05 · Draft
pending_approval
Sarah — Acme's engineering blog describes moving to Kubernetes in March, and there are four engineering roles open now, two of them infrastructure.
That combination usually means the platform work lands on whoever has capacity that week, and nobody owns it.
I do two-week infrastructure audits that end in a written report. Worth a look, or is someone already on it?
Architecture
An agent here is a prompt, an input/output contract, and a place in the pipeline. There is no agent runtime: a scheduler calls a model, the response is validated against a JSON schema, and the result is written to Postgres. The hard problem was scheduling and state, and that was already solved.
Runtime
Models
Enforced in the database
Live activity
A list tells you a company exists. None of the rest of it is on the list.
Everything above collapses into one row a person can approve in five seconds — or reject, with the reason kept.
The usual loop
Foldnine
Controls
Scores the model returns are capped in code, and the decision-maker component is replaced from the database rather than trusted. A model talked into something can produce a bad row; it cannot execute anything.
Nothing an agent returns is used to build SQL, a shell command, or a URL to fetch. Every response is validated against a schema before a row is written.
A database trigger rejects any message to a suppressed address outright. There is no removal path in the workflows, by design.
An address is stored only when the company published it, or when it follows a pattern that company itself published — marked as the inference it is. Blind guessing produces more addresses and no evidence, so it is not implemented.
Build state
Nine of fourteen workflows are built. The five that are not are the five that touch a mailbox. This page would be easier to write without this section; it would also be worth less.
| ID | Workflow | State |
|---|---|---|
| WF-02 | Company Research | Built |
| WF-03 | Contact Enrichment | Built |
| WF-04 | Lead Scoring | Built |
| WF-05 | Outreach Generation | Built |
| WF-10 | Telegram Dispatch | Built |
| WF-99 | Error Handler | Built |
| WF-100 | Daily Report | Built |
| WF-101 | Agent Health | Built |
| WF-01 | Lead Discovery | Specified |
| WF-06 | Outreach Dispatcher | Specified |
| WF-07 | Follow-up Engine | Specified |
| WF-08 | Inbox Classifier | Specified |
| WF-09 | Conversation Agent | Specified |