From one customer’s workflow to a reusable AI product.
I built Agency Edge to turn incomplete relationship records into research staff could review and use. Starting with a photography agency, I adapted the shared application for two schools. All three were paying customers. For San Francisco University High School (UHS), I delivered a workbook that kept each constituent’s existing record ID, so staff could review the results and prepare an import without connecting Agency Edge directly to their CRM.
I led discovery and personally implemented the frontend, services, data models, integrations and background jobs using AI coding tools. Collaborators contributed commercial work, quality review and delivery coordination.
On this page
From missing emails to a reviewable delivery
UHS advancement staff needed email data for constituents whose records were incomplete. We started with their file and constituent IDs, used Agency Edge to research candidate emails with known identity context, and returned original and enriched data in a workbook. Staff could compare the results and prepare an import using their existing IDs; the delivery did not require a live CRM connection.
The application began with a family-linked photography agency’s Salesforce and Campaign Monitor workflow. I adapted the same research and review capabilities for schools with different fields and delivery requirements.
Three paying organizations, distinct deliveries
- Photography agency
Keep campaign contact data current inside the agency’s existing Salesforce and Campaign Monitor workflow.
Seven-day report dated December 4, 2024: 950 new email addresses added and 819 bounced addresses removed. In February 2025, the agency described finding an Agency Edge photographer recommendation already in Salesforce while following up with an outreach respondent.
The follow-up shows use of enriched context, not attribution for the response or a sale.
- School adaptation
Give staff structured athletics, arts and academic-interest fields for event and reunion audiences.
An August 2025 paid delivery reported 70K+ updated field values, with originals and confidence information.
The count is field values across alumni and other constituents, not people or independently verified facts.
- San Francisco University High School (UHS)
Deliver email data in a workbook staff could review and import using their existing constituent IDs, without requiring live CRM access.
The October 2025 workbook contained 156 populated email records across 498 delivered rows, with original constituent IDs preserved. UHS paid and posted a referral in February 2026.
Delivery, payment and referral support this engagement; they do not establish a completed CRM import, retention or recurring revenue.
I implemented these controls so accepted research could follow the customer’s destination rules.
- Map the field
- Pair an application field with the corresponding field in the customer’s connected system.
- Choose the direction
- Control inbound sync, outbound sync and enrichment separately for each field.
- Protect existing values
- The selected rule, “Sync if CRM is blank,” keeps a new result from overwriting a populated destination field.
Check the identity behind the fields
In April 2025, a school found a wrong-person match in a 160-record sample. A team audit reported nine incorrect entries in that sample. The feedback identified missing cross-checks: education timing, employer history and location. This historical sample was not a measure of overall accuracy.
I expanded existing field confidence into hybrid AI-and-rules scoring at field and contact levels, comparing source evidence with that known context. By May 20, I had implemented match scoring. The change made the identity behind a plausible field part of the review.
On June 26, I demonstrated field confidence, original/proposed comparisons and edit/accept controls to UHS using demo records. I reused the approach in later customer work and ongoing agency enrichment. Confidence guides review; it is not a calibrated probability of correctness.
Synthetic example
| Field | Known record | Candidate source |
|---|---|---|
| Name | Jordan Lee | Jordan Lee |
| Employer | North Studio | East Company≠ |
| Education | Example University | Sample College≠ |
| Location | Oakland | Boston≠ |
Email supported. Identity unresolved.
Identity review required.Preserve the current record.
Illustrative evidence. No customer data or calculated scores.
AI research and application rules
A useful research result may belong in the application before it is eligible to change a CRM. In the evolved implementation, I separated proposed information, accepted application data and destination eligibility with typed changes, destination mappings and overwrite policies. Changing an email clears verification tied to its previous value.
I built the React and TypeScript interface, Python and Flask services, relational records and background jobs.
Conceptual workflow, based on the later implementation
Source records + known contextSource IDs, existing values and known employer, education and location
- Model-dependent interpretationResearch candidate values
AI interprets candidate sources against known record context and supports research summaries, biographies and categories. The workflow retains proposed values and supporting evidence for review, while AI and application checks inform field and contact confidence.
- Human judgmentChoose which changes to accept
Inspect original/proposed values and supporting sources. Accept useful changes; keep uncertain or conflicting identity matches in review.
- Deterministic application rulesRecord the accepted value
Apply typed fields and clear verification tied to a replaced email.
Preserve source IDs and the original/proposed comparisons needed for review and import.
Require a connected destination, mappings, outbound settings and an allowed overwrite policy.
Simplified view of the later implementation. Earlier deliveries used different versions. Eligibility does not itself confirm an external update.
Inspect the connection-state interface
Adapt the workflow without rebuilding the product
The UHS workbook carried one aggregate confidence score per record; field scores were available separately in the application. The delivered format could change while research and review stayed shared.
A common application supported different customer records, review needs and delivery paths.
| Shared capability | Customer-specific choice |
|---|---|
| Ingestion and field mapping | Agency CRM records or school uploads, with each customer’s source identifiers and field names preserved. |
| Research and proposed values | Agency contact and company context; school email recovery and structured athletics, arts and academic interests. |
| Confidence and review | Known identity context, original/proposed comparisons and the fields staff needed to inspect. |
| Delivery | A connected agency workflow or a reviewed school workbook. Destination mappings and overwrite rules apply where synchronization is used. |
Shared capabilities evolved across engagements. Customer configuration and product versions differed.
What did not convert
Another school pilot needed personal email addresses, but too much of the recovered data was work email. The pilot did not convert to a larger paid engagement. A populated field was not enough: the type of information had to fit the customer’s intended outreach.
Try an email update
Finding useful information, accepting it, and updating a customer system are separate decisions.
- Review and accept. An accepted email changes the application value and clears verification tied to the old address.
- Check permission. In this example, identity, current-email verification, mapping and destination permission must pass before a write is eligible.
- Confirm the change. Eligibility does not confirm a destination update. This demo changes the displayed CRM value only after simulated confirmation.
Synthetic data. No customer systems connected.
Proposed emailjordan.new
A candidate email was found. Both stored values and the original email’s verification are unchanged.
Checks and all three scenarios
Current checks
- Identity
- Identity match needs review.
- Email verification
- Verified: jordan.old@example.com only.
- Write eligibility
- An accepted value alone cannot update a destination.
- CRM confirmation
- Unchanged. No write confirmed.
Three scenarios
- Ambiguous identity. The proposed address is jordan.new@example.org, but the identity match is ambiguous. Review is required before accepting it. The application and simulated CRM both keep jordan.old@example.com; its existing verification remains attached to that original address. Finding a candidate is not permission to replace a value.
- Accepted value, blocked destination. Accepting jordan.new@example.org changes the simulated application value and clears the old email’s verification. The new address is unverified. Checking eligibility reports that destination-write permission has not been granted, so the simulated CRM keeps jordan.old@example.com. Acceptance inside the application does not grant permission to write elsewhere.
- Eligible destination. First accept jordan.new@example.org, which changes the application value and clears stale verification. Then simulate a separate verification of the new email. Check destination eligibility: in this scenario, identity review, current-email verification, field mapping, and destination-write permission all pass. The simulated CRM still keeps jordan.old@example.com. Only an explicit simulated connector confirmation changes it to jordan.new@example.org and marks the operation complete.