Company and person data built for human operators optimizes for the search page: filters, counts, an export button. Company and person data built for AI agents optimizes for something else entirely - fields an agent can plan against, provenance it can reason about, freshness it can weigh, and a cost per call it can budget. The same underlying facts, packaged for a consumer that never looks at a screen and never stops asking "how do I know this is true and when did I learn it".
This guide covers that packaging from both sides. The company families and what each is good for, the person families and the reach fields that decide whether a record is actionable, the identity-resolution layer everything keys on, the data contract an agent needs from every source, how records become account plans, the delivery targets where the data actually has to land, and the compliance rails that keep person data inside the law. It reflects how the company intelligence agent and the prospecting agent consume the catalog.
Why agents need different data than people do
A person using a data tool supplies judgment at every step: they notice the employee count looks stale, they recognize that two similarly named companies are different, they decide the phone number is worth the credits. An agent has to make those calls from the data itself, which means the data has to carry what the person was silently supplying. Schema: fields typed and named consistently, so a plan can say "filter on employee_count between 200 and 2,000" and mean the same thing across sources. Provenance: the source, date and confidence on each value, so the agent can prefer an observed value over an inferred one and know when a field is due for refresh. Freshness: timestamps that let the agent weigh a technographic observation from last week differently from one from last year. Cost: a known price per call, so the agent can reserve it against a ceiling before spending and stop when the budget says stop. The retrieval architecture underneath an agent is only as good as what the retrieved record tells it about itself.
Company data: the six families
| Family | Fields | Decay | Best for |
|---|---|---|---|
| Firmographics | Size, industry, revenue band, headquarters, founding year, ownership | Quarterly | ICP filters and fit scoring |
| Technographics | Stack, adoptions, changes, removals, each with a detection date | Weeks to months | Displacement and complement prospecting, timing |
| Funding | Rounds, amounts, dates, investors | Event-driven | Budget timing and account plans |
| News | Launches, expansions, executive moves, partnerships announced | Weeks | Openers and account-plan context |
| Relationships | Integrations, partners, customers, suppliers, parent and subsidiaries | Slow | Ecosystem routing, suppression of subsidiaries of customers |
| Location | Offices, service areas, local-business listings and categories | Slow | Territory lists, local and regional prospecting |
Two families are underused. Relationships turn a company record into a graph: a target that is a subsidiary of a customer belongs on the suppression list, and a target that integrates with a partner belongs on a co-selling list, and neither is visible from firmographics alone. Location is where B2B data tooling has historically been thinnest, because local and regional businesses live in listings and categories rather than in funding databases - and a territory list of regional firms by category and service area is a company-data job like any other. The glossary entries for firmographic data and technographic data carry the short definitions.
Person data: title, seniority, department, reach
A person record has two halves. The role half - title, seniority, department, the company they hold it at - is what makes a person the right person: the head of ecommerce, a director-level owner in operations, the first data hire. Titles are noisy and seniority and department are the normalizations that make them filterable, so a source that returns only a raw title string is handing the agent a parsing job. The reach half - a verified business email, a verified direct or mobile number - is what makes the person actionable, and it is the half most sources are weakest on. A record with a role and no verified reach is a research note; a record with reach that was never verified is a bounce waiting to happen. The verification verdicts and the actions each one deserves are in the scoring, verification and hygiene pillar.
2 halvesa person record is a role and a reach; agents treat the record as unfinished until both are filled and the reach is verified
Identity resolution: names to domains, people to companies
Everything keys on identity, and identity is the step most likely to go quietly wrong. A list from a conference arrives as company names; a CRM segment carries domains typed by hand; a partner's CSV mixes both. Resolving a name to the right domain - not the similarly named company two industries over, not the subsidiary, not the acquirer - is a waterfall of its own, and the firmographic pass that follows is its confirmation step: if the resolved domain's size and industry contradict what the list said, the resolution is suspect. People resolve the same way, to a role at a specific resolved company rather than to a name that matches somewhere. A wrong domain poisons every field enriched on top of it, which is why identity runs first in every waterfall and why the confidence on it travels with the row.
The data contract an agent can plan against
The contract is what makes sources comparable and waterfalls orderable: two sources that both return employee counts under the same schema with provenance and timestamps can be measured against ground truth per segment, and the measurement sets the order. It is also what makes the agent's own output trustworthy, because a row assembled from contract-compliant sources can show, field by field, where every value came from and how sure the run was. Sources that break the contract - undated values, estimates presented as observations, silent nulls - are the ones that produce confident wrong rows.
From records to account plans
Company and person data become intelligence when they are assembled per account with the evidence attached: the firmographic fit, the stack and what changed in it, the funding and where it flowed, the buying committee with roles and verified reach, the signals that fired this quarter and the momentum read they add up to, and the relationships that shape how a deal will move. An account plan built that way is a document a rep can act on and an auditor can check, because every claim in it links to a dated source. Segment reports are the same assembly over a list - which industries, sizes and stacks the segment actually contains, with the counts computed rather than eyeballed - and the momentum section of an account plan is built from the reading discipline in tracking account hiring and funding signals.
Delivery: where the data has to land
A finished record that lives in the data tool is a finished record nobody uses. Four destinations cover practice. The CRM, where writes must be idempotent, respect existing observed values and carry provenance into the fields the CRM can hold. Sheets and CSV, for review, for operators who live there, and for the platforms that accept a file. Outreach tools, where the record arrives with the evidence and the first touch attached so the sequence starts from context. And ad accounts, where the same rows become matched and custom audiences. Every one of those is an external write, and every external write deserves the approval gate and the audit entry described in approval queues that keep autonomy fast.
Compliance and the suppression rails
Person data is regulated data. Under the EU's data protection rules and the state privacy laws that followed in the US, processing business contact data for outreach rests on a documented basis, honors opt-outs and deletion requests, and stays inside the purpose it was collected for; the ad platforms add their own policies on where uploaded lists may come from. For an agent program that means three rails built into the pipeline rather than into a policy document: a maintained suppression list - opt-outs, deletions, do-not-contact - applied before every sequence and every audience; provenance on every person field so the basis for holding it can be shown; and the audit log that records what was written where and who approved it. Compliance is a property of the system when the rails are enforced, and a hope when they are not.
How AstroFabric does it
AstroFabric's data catalog is built for agents from the ground up: every field typed, every value carrying its source, date and confidence, every call priced before it runs and charged only when a source answers, and every miss returned as a structured no-answer the agent can plan around. The prospecting agent identifies companies by firmographics, technology, hiring, funding, similarity to your best customers or location, including local businesses, and finds the people by title, seniority and department with verified emails and phones where findable. The company intelligence agent assembles account plans, segment reports and charts over any list or company, with the evidence attached. The verification agent runs verification, dedupe and the suppression rails.
Everything is reachable the way an agent needs it: the console for people, the REST API and the hosted MCP server for assistants and code, the CLI for scripts, and Slack, Telegram and email for the team. Delivery into CRMs, sheets, outreach tools and ad accounts passes an approval gate, every run is bounded by a credit ceiling, and the audit log records the provenance behind every field. The agentic AI for company data and agentic AI for person data pages map the two halves of the catalog.
Go deeper in this cluster
- AI agents for waterfall data enrichment: the complete guide - Why one data source never fills a list, how a waterfall runs field by field with provenance on every value, the ordering and conflict rules that keep it honest, and what changes when an agent plans the waterfall instead of a person.
- What is technographic data? - Technographic data is the record of which technologies a company uses - detected, dated and tracked over time. What it observes, how it is collected, why the changes matter more than the snapshot, and how it is used in prospecting and enrichment.
- What is firmographic data? - Firmographic data describes what a company is - size, industry, revenue, location, ownership, age. The fields, where they come from, why observed values beat estimates, and how firmographics anchor ICP filters, fit scores and every waterfall that follows.
- What is waterfall enrichment? - Waterfall enrichment fills an empty field by trying data sources in order and stopping at the first trustworthy answer. The definition, a worked example, why it beats a single source, and the two rules - provenance and pay-on-answer - that keep it honest.
- AstroFabric vs Ocean.io: lookalike discovery or the whole chain after it - Ocean.io is the specialist for lookalike account discovery: paste your best customers, get the companies that resemble them. AstroFabric runs the lookalike step and everything after it - people, verification, enrichment, signals, audiences - as agent missions. The honest map, with September 2026 pricing.
Frequently asked questions
What is a company data API?
A programmatic interface that returns typed company records - firmographics, technographics, funding, news, relationships, location - for a name or a domain, with provenance and timestamps on each value. For AI agents the contract matters as much as the coverage: schema, confidence, cost per call and a structured no-answer.
What is the difference between firmographic and technographic data?
Firmographics describe what a company is - size, industry, revenue band, headquarters, ownership - and decay slowly. Technographics describe what it runs - the stack, and the adoptions, changes and removals in it - and decay in weeks to months, which is why the dated events matter more than the static snapshot.
What makes person data actionable?
Two halves: a role (title, normalized seniority and department, at a resolved company) and verified reach (a business email verified deliverable, a phone verified connected). A record with a role and no verified reach is a research note; reach that was never verified is a bounce waiting to happen.
Why does identity resolution matter so much?
Because every other field is enriched on top of the resolved domain. A name resolved to the wrong company - a namesake, a subsidiary, an acquirer - produces a row that is confidently wrong in every field, so identity runs first, the firmographic pass confirms it, and its confidence travels with the row.
What should a data source guarantee to an AI agent?
A schema with typed, consistent fields; provenance on each value; a confidence level; an observation timestamp; a known cost before the call, charged only on an answer; and an explicit structured no-answer instead of empty strings or fabricated values.
How do agents stay compliant with privacy law when handling person data?
By building the rails into the pipeline: a maintained suppression list of opt-outs and deletions applied before every sequence and audience, provenance on every person field so the basis for holding it can be shown, and an audit log of what was written where and who approved it.
Sources
- European Commission - data protection rules governing person data
- California Privacy Protection Agency - the CCPA and its regulations
- Gartner - the B2B buying journey research behind buying-committee data
- Model Context Protocol - how assistants call typed data tools
Every playbook on this blog ships as a runnable mission.
Open a workspace and the playbook library is waiting - describe the outcome and the agents carry it end to end, on your plan's monthly credits.