The Assistant Reads Your Data. It Doesn't Learn It.

When we built the AI assistant inside the Freedom Ag portal, the first question Derek asked was how long it would take to "train" the system on all the products in the catalog.

We didn't train it on anything.

The assistant doesn't know what's in Freedom Ag's product catalog until a rep describes a job and asks for a spray card. At that point, it calls a function that reads the current product records, matches the application to the right SKU, pulls the label rate for that crop and pest combination, and writes the spray card from the live data. Add a new product next week and the next spray card immediately includes it. Change a label rate and the next card reflects the change.

The same pattern runs inside the Homefront portal. When a provider starts a session note, the AI assistant doesn't have a general idea of what First Steps goals look like. It calls a function that reads that specific child's current IFSP goals: the exact language from the record, the service type, the goal target. It drafts the note from the live document, not from a training example.

The distinction matters in practice.

A trained model knows what it knew at training time. If you fine-tune a model on your product catalog in March and add twelve products in April, those twelve products don't exist to the model unless you retrain. Retraining is expensive, slow, and requires someone to curate training data. For a business that changes prices seasonally, adds products continuously, or tracks per-client compliance documents, a trained snapshot goes stale before it's useful.

Function calls solve this differently. The model doesn't learn your data. It gets access to tools that read your data at request time. The model decides when to call a tool, calls it with the right parameters, reads the result, and uses it in the response.

In the Freedom Ag case, the tools are: read customer record, search product catalog by crop and application type, look up label rate, write spray card to the job record. In the Homefront case, they're: read child IFSP, read authorized units for this service type, draft session note using goal language from the IFSP.

The model doesn't need to know Derek's catalog is 200 SKUs or that a particular product was added last Tuesday. When a rep describes a herbicide job for corn, the tool call returns the matching records and the model reasons over what it got back.

What this means for maintenance.

When you train a model on your data, keeping it current is a second job. When the model reads live data through functions, the current state of your database is always what the assistant sees. No retraining cycle. No stale answers. No gap between what the assistant thinks is in the catalog and what actually is.

Both portals use this pattern because both portals have data that changes: products get added, labels get updated, children get new IFSP goals, authorizations get renewed. The assistant has to know the current state, not last month's state.

The tradeoff is that building the tools requires actual database integration: schema knowledge, query design, output formatting the model can work with. That's the build cost. The ongoing cost, unlike fine-tuning, is zero.