Source-backed exampleUpdated
Lead enrichment AI agent backend: an agency handoff example
In brief
This lead enrichment example starts from a pilot seed defined in the Axtra product: accept a lead payload, enrich company context, score buying intent, explain the score, flag missing inputs, and return CRM-ready JSON. It demonstrates the requirement and handoff contract; it is not a customer case study or a claim that a public endpoint is live.
Signal map
Turn a lead payload into a reviewable response contract.
Lead payload
emailcompanyrolewebsitenotesEndpoint
POST /runCRM-ready output
lead_scorecompany_profilefit_reasonmissing_inputsnext_action
Source of truth
The repository-backed pilot requirement
AI-agency pilot seed
Agency lead enrichment API
Build a lead enrichment agent for an AI-agency client. Accept a lead JSON payload with email, company, role, website, and notes. Enrich the company profile, score buying intent from 0-100, explain the score, flag missing inputs, and return CRM-ready JSON with next_action.
This text comes from the same source constant used by the product’s agency pilot entry point. Keeping the example tied to that source reduces the chance that the public contract drifts from the workflow a user can start.
API contract
Expected endpoint and output contract
Accepted input
emailcompanyrolewebsitenotesEndpoint
POST /runCRM-ready output
lead_scorecompany_profilefit_reasonmissing_inputsnext_action
The seed accepts email, company, role, website, and notes, then asks for a 0–100 buying-intent score, enriched company context, an explanation, missing inputs, and the next CRM action. The approved specification should make validation and error behavior explicit before generation.
Six evidence states
The evidence path for this example
- 01
Input
Requirement
Capture the client workflow, accepted lead fields, scoring rule, missing-input behavior, and CRM-ready response.
- 02
Gate
Approved specification
Review the endpoint and typed contract before generation. Approval is required before the proposed behavior becomes the build contract.
- 03
Build
Versioned artifact
Generate the agent workflow and backend source as an artifact that can be inspected and downloaded.
- 04
Proof
Validation evidence
Run the configured checks against that exact artifact version and preserve the result with it.
- 05
Revision
Edit and version
If the scoring or response contract changes, create a new traceable version rather than overwriting the evidence boundary.
- 06
Handoff
Download or deploy preflight
Hand over the artifact, or verify lane configuration before deployment. A blocked preflight is not a live endpoint.
The implementation guide explains why each boundary is separate.
Reference library
Three prompt-backed use cases
The lead-enrichment page above is tied to a product-owned seed. The following pages serve a different purpose: they turn acceptance-corpus prompts into reviewable input, rule, output, and boundary-test contracts without claiming generated artifacts.
Claim boundary
What this example proves—and what it does not
It proves that Axtra carries a concrete, source-backed agency seed with an endpoint and expected output fields. It also shows the evidence the workflow is designed to preserve from approval through handoff.
It does not prove customer adoption, a measured business result, certification, or a universally available hosted endpoint. Those claims require separate evidence and are intentionally not made here.
This page proves
A source-backed seed, endpoint, expected fields, and an explicit evidence path exist.
This page does not prove
Customer results, certification, or a universally available live endpoint.
Continue reading
Related resources
Move between the agency workflow, implementation guide, proof, reference scenarios, and comparison.