My daughter’s school needs to raise money for expansion.
I’d been building AI-Native GTM at Bolo AI, and I started applying that approach to the school’s fundraising work.
Who should we get to know? What makes them relevant? What have they supported before? Is there someone who could introduce us? Where might we have an opportunity to meet them?
Then, once a conversation starts, how do we keep track of it and follow through?
That became Magnolia Intel.
It combines public-record research, a structured database, AI agents, and a CRM. The intended workflow runs from the first signal through research, relationship building, the ask, and the outcome.
The application is working, and several research processes are built. Some collection runs on a schedule. We’re still developing other parts, including broader automated event discovery, while checking the identities and evidence underneath the records.
Here’s how I’m thinking through the system, starting with the research that feeds it.
The plan prior to sourcing research
A school raising money for expansion needs to understand who has supported similar work and how those relationships developed.
Has a person or foundation funded education? Was it scholarships, operating support, or a capital campaign? Did they give once or support an institution over several years?
Who was involved? Does someone at our school have a connection? Is there an application process, or would the next step be a conversation?
Those questions determine what we look for.
A foundation’s assets tell us something about its resources. Its grants show where money has actually gone. A board appointment tells us about a particular role at an institution. An event announcement might identify someone chairing an upcoming fundraiser.
I think of those as signals: specific observations that could change what we research or do next.
The signal needs context. A date, a source, a recipient, a role, a purpose. Those details help us decide whether it is relevant and what it actually establishes.
IRS filings and aligned giving
IRS filings provide a substantial part of the foundation research.
They give us a way to examine the organization’s reported finances, grants, and officers or trustees. We can begin with a foundation, look at its giving, and investigate the recipients and people connected to it.
For the school, the useful questions go beyond the size of the foundation. What has it funded? What kinds of institutions appear among the recipients? Is there a history worth examining across several filing years?
The record also needs to retain the distinction between the year covered by a filing and when we retrieved it. Finding a document today doesn’t make the activity in it recent.
The collection process works with machine-readable filings where available. That allows code to extract structured information such as grant recipients and officer names.
But extracted names still need to be resolved. A recipient identified by an EIN gives us a stronger match than an organization name alone. A trustee’s name may need additional context before it can be connected to a person already in the database.
The filing is the beginning of that research process.
Smaller institutional records
The research gets more specific when we look at what institutions publish about their own communities.
Church bulletins. Annual reports. Event programs. Donor acknowledgments. Committee lists. Board announcements. Older articles about a school’s capital campaign.
A bulletin may acknowledge support. A program may name a sponsor or committee member. An annual report may recognize someone within a giving range. An article may describe how a relationship developed into a gift.
Some of that information is several pages into a PDF. Some appears on a web page that has barely changed in years. The same name may appear in several places, in different roles, across a long period.
That is the depth we’re building toward.
The purpose of looking in these sources is to find attributable details about documented participation and support. We need to know what the institution actually reported before drawing any further conclusion.
We already collect foundation filings and have extraction processes for philanthropic coverage. The broader institutional-source collection is still being developed. Each source type needs its own method and checks.
A sponsor tier also needs to stay a sponsor tier. If a page defines a minimum for a category, that does not establish the exact amount a named sponsor contributed.
Likewise, serving on a committee, sponsoring an event, and attending it are different observations. The collection process needs to preserve the wording and context that distinguish them.
Preserve what each source actually says
During review, we examined a public announcement about a matching pledge to a school’s capital campaign.
The amount alone left out the commitment’s terms. It was a joint pledge with a matching condition and a defined campaign period. The announcement did not, by itself, establish that the full pledge was subsequently paid.
Those details change how the information should be recorded. The next research step is to look for later reporting about the campaign and its completion. The original school announcement provides a bounded historical claim.
We also encountered the problem of a newer page describing an older event. A publication date can be different from the date of the underlying gift or relationship.
This is the kind of detail that needs a home in the database. Otherwise, a specific source becomes a vague summary, and the next person or agent can read more into it than the source supports.
Building an ontology around the research
We built the application first. As the research grew, I paused new app features to strengthen the database underneath it.
The original prospect records were too limited for some of the things we needed to represent.
A person might work at a company, serve as a foundation trustee, and chair an event. They may matter to the research without ever becoming someone the school approaches for a gift.
Two people can make a gift together. A foundation can make a gift publicly associated with its founders. A household and a person need different records.
The ontology defines the types of things we track and the relationships between them.
For Magnolia, that includes people, households, families, organizations, places, and events. Organizations can have different roles, including foundations, schools, nonprofits, and companies. Giving records connect a donor to a recipient and preserve the type of commitment.
Being a prospect belongs to the campaign relationship. The person’s identity should exist independently of whether we decide to pursue them.
That lets someone remain in the research as a trustee or potential connector without automatically turning them into a fundraising prospect.
The relationships need explicit meanings. A person is a trustee of an organization. Someone chaired a particular event. A foundation made a grant to a school.
Time belongs in that structure too. A board role may have ended. An event has a specific year. A gift may have an announcement date and a separate payment date.
We use PostgreSQL through Supabase to store these records. Relationships live alongside the identities, evidence, and other structured information, so we can ask questions across them.
The diagram explains the structure. We still have to check the records inside it.
Separate source observations from resolved facts and decisions
There are several steps between finding a document and recommending an action.
First, we register the source and the retrieved document. Then extraction produces observations: what the source reported, the raw names it used, relevant dates, and the extraction method or version.
An observation can exist before we know exactly which person or organization it refers to. That gives us a place to hold useful information while identity remains unresolved.
Matching proposes where it belongs. Resolution connects supported observations to entities, relationships, or giving records. Evidence links preserve the route back to the source.
Human judgments have their own records. Someone can confirm a match, reject it, decide to pursue a prospect, or exclude a record from further research.
Scores are stored separately as well. They are assessments made from the available inputs, and we need to be able to examine those inputs.
Keeping these layers separate means we can revise an interpretation while retaining the original observation and the decision history.
It also helps preserve a person’s decision when another research run encounters the same material.
Identity resolution becomes part of the system
Names become difficult quickly.
A person may appear under a nickname in event coverage, a full name in a filing, and a name with a middle initial somewhere else. Couples may be listed together. Family members may share names.
During review, we found a mother and daughter represented with a spouse relationship. We also found multiple records that appeared to refer to the same person.
Those errors affect the rest of the system. Giving history can be split across duplicates. A relationship path can lead through another record for the same person and appear more useful than it is.
Claude can propose matches, but the reviewer needs the evidence and the reason for the proposal. Name similarity needs corroborating context.
A correction also needs to preserve the campaign history attached to the record. Merging two identities should not silently discard an application, an owner, or a prior decision.
We’re still working through the older records that need this treatment.
Give the agent a structured profile
Once observations have been connected to a record, the system needs a consistent way to retrieve them.
The profile interface includes the entity, aliases, relationships, giving records, freshness information, scores, and unknowns.
A relationship has a named type and direction. It can carry a role title, time bounds, and a count of supporting evidence.
That structure helps make the missing information visible too. If we don’t know the dates of a relationship, we should retain that uncertainty rather than silently treat it as current.
This gives an agent specific fields to work with when answering a question or preparing a brief. It also gives us something we can inspect when an answer is wrong.
An empty list in the profile means there are no returned records of that kind. It does not establish that the person has never given or has no relationships. We need to keep that distinction in the language generated from it.
Enrich the records
Once someone appears relevant, the next job is to build out the context that would help a person prepare.
For a foundation, enrichment can include filing information, trustees, documented grants, website details, application requirements, and deadlines.
The foundation enrichment process combines structured data with web research. Exa helps locate relevant public material, and Claude extracts information for the profile.
For people, the work involves bringing together documented giving, organizational roles, and relevant connections while checking that the observations belong to the right identity.
The internal brief then organizes the available research: who they are, what we know, where the evidence is thin, and a recommended first move.
A foundation with an open application process may require an application and a deadline. An individual may be better approached through a verified connection or a conversation at an event.
The brief should make the relevant background easier to use while keeping uncertainty visible. It is preparation for the person doing the work.
Prioritize with evidence people can inspect
The application also has scoring processes for foundations and individuals.
They use different models because the research questions differ. Claude assesses components from the evidence supplied, and code calculates the combined score.
That keeps the arithmetic consistent. The harder question is whether the underlying information supports the assessment.
A precise number can still rest on incomplete research or an incorrect identity match. Our review found legacy scores alongside records that needed more work, so a score needs its context.
I want prioritization to help the team decide where to spend attention. The explanation should remain accessible, and a person’s judgment should have its own place in the record.
Find the events worth attending
Another part of this is deciding where we should show up.
We’re building toward an event research agent that finds upcoming gatherings and compares published participants with people and organizations already in our records.
Who is chairing it? Who is being honored? Who is on the host committee? Does the event involve someone we’ve wanted to get to know?
The recommendation needs to explain why the event matters and what supports the connection.
Published roles help establish specific involvement. Someone named as this year’s chair has a different relationship to the event from someone mentioned in coverage of an earlier year.
Historical participation can give us a reason to investigate, but it does not confirm future attendance. The same applies to an institution’s sponsorship: it does not establish that every trustee will be there.
The current application has an events feed, matching, and event detail pages. The broader automated event-finding process is still part of the build ahead.
The team can review an event, decide whether to attend, and assign someone to represent Magnolia. That creates a practical next step for the research.
Preparing approaches advancement team can use (still a work in progress)
The system has a dedicated agent for drafting short openers.
The sender’s relationship to the school matters. A parent explaining why the school matters to their family has a different starting point from a board member asking for an introduction.
The situation matters as well. A first email, a conversation at an event, and a follow-up afterward need to reflect what actually happened.
The opener’s instructions lead with Magnolia’s mission and the sender’s connection to the school. The prospect’s giving record stays in the internal research rather than being recited back in the message.
Where an introduction is appropriate, we need to verify that someone can make it. A shared institutional connection gives us something to investigate.
The person making contact reviews the draft, adapts it to the relationship, and decides what to send.
Record what happens
The event workflow continues after someone attends.
Who did we meet? What was discussed? Is there a follow-up? Did someone offer to make an introduction or suggest another person we should speak with?
The app has a place to record the event report and contacts met. That lets the next person working on the relationship understand what happened.
A public source can tell us that someone chaired an event. Our own activity record can tell us that a person from Magnolia met them there. Those are separate sources of information, and both can become useful to the team.
Track the relationship from signal to close
Magnolia Intel operates as a CRM as well as a research application.
A new name enters the inbound queue. Someone reviews it and decides whether to pursue it. Once it becomes active, the prospect has a place in the pipeline, with research and campaign activity attached.
That activity includes conversations, meetings, school tours, applications, and outcomes.
The pipeline gives the team a shared view of the work. What stage is this relationship in? What has happened? What needs attention next?
A parent may know someone personally. A board member may make the introduction. Another person may handle a foundation application.
The record should let each of them understand the relevant history without asking everyone else to reconstruct it.
An event conversation may lead to a tour. A tour may lead to another meeting. An application needs its request, submission, and outcome recorded. The intended process carries that work from the original signal through the ask and eventual close.
When an opportunity closes or is parked, the history remains useful. The next conversation may depend on knowing what was discussed and why the team made its earlier decision.
Each agent gets a defined role (still a work in progress)
There are several distinct jobs in the system.
Discovery looks for new research candidates. Collection retrieves source material. Extraction identifies observations in it. Matching proposes which records they belong to.
Enrichment builds out a profile. Scoring helps prioritize review. The brief writer prepares internal context. The opener drafter prepares language a person can adapt.
The event-research direction adds another job: finding relevant opportunities to meet people and explaining why they matter.
These processes need different inputs and outputs. Some use ordinary code. Others benefit from a language model.
A filing parser can extract structured fields directly. An article may need interpretation. Composite-score arithmetic belongs in code. An ambiguous person match needs evidence and review.
The app includes an Agents page showing roles and prompts. Prompt edits have version history, giving us a record of changes to the instructions used by those parts of the engine.
That makes it easier to examine an individual process when something goes wrong.
Repeatable Research
New filings appear. Roles change. Events are announced. Older information needs revisiting.
Some collection runs on a schedule through Vercel. Jobs process bounded batches and record their progress.
A recent collection failure led us to improve checkpointing. The process needed to preserve completed work so an interrupted run could resume from its progress.
We also need to distinguish a scheduled job being invoked from useful collection actually finishing. Run records should tell us what was retrieved, what was written, and what failed.
The first successful run after a repair establishes that the process worked in that instance. We still need to observe it over time.
These operational details affect the research someone sees in the application. A profile’s freshness depends on the underlying collection and review, not on how recently someone opened its page.
Building the stack to work together (still working on this!)
Next.js and React provide the application screens.
Supabase provides sign-in and the PostgreSQL database. PostgreSQL holds the identities, relationships, observations, evidence, and campaign records.
Exa supports web discovery. Claude handles selected interpretation, matching proposals, research briefs, and opener drafts. Vercel hosts the application and runs scheduled jobs.
The full process starts with a source. Collection retrieves it, extraction produces observations, and resolution connects supported observations to records. Review handles decisions that need a person.
Profiles, briefs, events, and the CRM give the team ways to use that information and record what happens afterward.
That sequence is also how I’m evaluating the build. Can we retrieve the relevant information? Preserve what it means? Connect it to the correct record? Help someone decide what to do? Retain the result when they act?
Where we’re at today
We have a working application and several functioning research processes. We’re still improving the identities and evidence underneath them, and broader automated event discovery remains part of the work ahead.
The current test is a small set of prospect records.
Get the people represented correctly. Attach documented giving with the right attribution and dates. Check the institutional connections. Prepare a brief that makes the unknowns clear.
Then work through the next step with the school: choose an approach, prepare for the interaction, and record what happens in the CRM.