Agency Edge / Hands-on AI building
Making AI-derived data useful in a customer’s workflow.
I built an AI-backed relationship-data application around recurring contact research and audience selection, then adapted its review and delivery workflow for independent-school customers, including a signed, paid UHS engagement.
Start with the work people repeat.
At an agency, staff repeatedly researched contacts who changed jobs or email addresses, then categorized people for relevant campaigns. Salesforce held relationship data; Campaign Monitor supported outreach. Stale records affected reachability, while manual tagging made audience selection repetitive. The useful problem was helping the team reach the right people with the right work.
I learned that workflow directly from the operating team. Agency Edge evolved from CodeBuddy into software for researching incomplete relationship data, reviewing candidate changes, and returning information to the places customers worked. I built it part-time alongside my full-time Product Manager role at Swish, using ChatGPT, Claude, and later Codex for implementation.
The early agency workflow connected Salesforce and Campaign Monitor and included bounded automated email cleaning. Later feedback made the product standard sharper: staff needed to understand what they could stop doing, what the application would handle, and which exceptions still needed attention. A new dashboard was only useful if the surrounding workflow made sense.
Decision 01 — Preserve identity, simplify the handoff
Fit the delivery to the customer’s existing system.
UHS, an independent school, provided a distinct commercial test. Its team wanted missing alumni information in a form they could review and prepare for their existing system. I built and demonstrated the product; our team worked through a pilot, scope, agreement, and delivery with the school.
For the engagement covering approximately 500 alumni, we delivered a reviewed workbook. We preserved the school’s source identifiers so each result could be reconciled to its original constituent record. The identity was the key, not the spreadsheet’s row position: the starting and enriched sheets had matching identifier sets, with different row orders.
The engagement had a signed scope, and UHS paid after our October 2025 delivery. The customer posted a referral in February 2026. The workbook was the completed customer handoff. It did not require a live Blackbaud integration or a move into a new system. That bounded delivery gave us a concrete outcome without expanding the engagement beyond the customer’s task.
Decision 02 — Make uncertainty change the workflow
A plausible record can still describe the wrong person.
In a separate engagement with another school, a customer found a wrong-person match during spot-checking. Several fields looked consistent because they came from the same incorrect profile. The failure was about identity, not just a single inaccurate field.
I investigated with the customer and made original-versus-enriched comparisons and confidence-oriented review more central to the response. The customer used those signals to prioritize checking and asked for field-level distinctions: one useful proposed value should not require accepting everything else in the record.
That feedback established a useful review outcome. It did not establish a new accuracy rate. My takeaway was to preserve the original context and make uncertain information actionable, so the customer could decide what to accept and what needed more evidence.
Decision 03 — Separate acceptance from external delivery
Give each step its own meaning of done.
I personally implemented the application across React and TypeScript, Python and Flask, relational data, integrations, and background processing. Each layer serves the operator’s task: contact and company relationships retain context; source mappings connect records to the customer’s system; review surfaces show proposed changes; background jobs carry longer-running research and delivery work.
The current implementation separates a proposed value, an accepted application value, and permission to write to an external destination. Applying a change includes typed values and dependent-data handling. If an email address changes, the old address’s verification is cleared. A new address cannot inherit evidence about a different one.
External write eligibility has its own checks: the connection, record and field mappings, outbound settings, and overwrite policy. An accepted value can therefore remain blocked from the CRM for a specific reason. Eligibility still precedes connector confirmation; the interface should not imply that finding or accepting information completed an external update.
Long-running work needs equally clear state. I developed shared progress, cancellation, and saved-scope retry contracts while retaining each workflow’s own job owner. A cancellation request is distinct from a finished cancellation, and retrying should preserve the original selected scope. These describe the current implementation; the earlier customer engagements had their own versions and operating arrangements.
Conceptual flow of the current application. Original explanatory reconstruction.
Useful software, tested by actual customer work.
Agency Edge brought together an operating agency workflow, independent paid delivery, and customer feedback that changed the product. I owned the application implementation; collaborators contributed substantial commercial and delivery work. UHS’s payment and later referral support the value of that engagement, without turning it into a recurring-SaaS or automatic-import claim.
The principle I take into AI product work is practical: generated information only becomes useful when identity, review, and destination behavior fit the customer’s task. The demonstration below makes one of those decisions tangible with synthetic data. It explains the product distinction; it is not a replay of customer records or a model-performance test.
A product decision you can try
A proposed email is not a completed update.
Found information, accepted information, permission to write, and confirmed delivery are four different states. The original value stays available for review. Accepting a new email clears the old email’s verification; an external destination changes only after its own requirements and confirmation.
Interactive demonstration using synthetic data. No customer systems are connected.
What happens after the AI finds a new email address?
Choose a scenario and follow a synthetic email update. Accepting a value, permission to write, and confirmed completion stay separate.
A candidate email was found. Both stored values and the original email’s verification are unchanged.
Read all 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.