Human-in-the-Wild

The best data in the shop isn't in the POS

Every recommendation engine I build starts with the system of record. For the flower shop I work with, that's Clover. I get sales by day, week, month and year, how bouquets sell against single stems and bundles, and what got substituted when something ran out. It's solid data, and it still misses the most useful knowledge in the shop, which is everything the owner knows and has never written down.

She knows which vendor's stems look great coming off the truck and look tired by Thursday. She can tell when a few customers asking for the same flower in one week means it's about to take off. She'll look at a seasonality chart and tell you the market she walked through that morning disagrees with it. None of that is in a database, and every bit of it should shape what the engine recommends.

Tacit and explicit knowledge

Explicit knowledge is anything you can write down and hand to someone else, like a price list, an SOP or a reorder threshold. Tacit knowledge comes from doing the work. It's the judgment you'd have a hard time explaining even if someone sat you down and asked. Michael Polanyi put it well back in 1966 when he wrote that "we can know more than we can tell."

Ikujiro Nonaka and Hirotaka Takeuchi built on that in the 1990s with a model of how organizations create knowledge by moving it between those two forms. They called the step of getting what's in someone's head into a shareable form externalization. It's the hardest part, and it's the part most companies skip.

Most companies are bad at this

I've seen a lot of documentation over the years, and it tends to break down the same way. Someone writes it at launch and nobody touches it again. The person with time writes it instead of the person who actually knows. It covers the steps but leaves out the judgment calls, so you know what to do but not when to ignore it. It sits in a wiki nobody opens when they need it. And keeping it current takes more effort than just remembering, so people remember.

The bigger issue is that teams never practice. Pulling tacit knowledge out of someone's head is a skill, and you only get good at it with reps. Most companies get one rep per person, a two-hour exit interview with someone who has ten years of context. Then that context leaves with them.

Small businesses have it worst because the owner is the documentation. There's no knowledge manager and no wiki, and she doesn't have a spare hour. If I ask her to fill out a form about her vendor preferences, I'm asking her to do data entry for software that's supposed to be saving her time.

What I'm building for the flower shop

The first version was a data science tool that emails the owner ordering suggestions for bouquets, single stems, bundles and substitutes. It factors in seasonality and pricing and reports daily, week-over-week, month-over-month and year-over-year sales. The goal is lower costs, less waste and more profit, and the agents behind it work against Clover's API.

The suggestions were good, but they only knew what the data knew plus whatever a model knows about flowers in general. When the owner disagreed with something, she had to tell me, and I had to change it. That made me the bottleneck, and it put a software engineer between a florist and her own expertise.

The next version connects the recommendation engine to an LLM she can text or email in her own words. She doesn't need to log into anything or learn a new tool.

Human-in-the-Wild

I went looking for a name for this and couldn't find one. Human-in-the-loop is the closest, and it's a good pattern, but the person in the loop is usually approving or rejecting something the agent already decided. The expert ends up working inside the agent's workflow.

Here it's the other way around. The owner keeps doing her job, and the agent picks up what she notices at the wholesaler, when deliveries come in and while she's talking with customers. I'm calling it Human-in-the-Wild (HITW).

A Human-in-the-Wild system has two layers of knowledge. The baseline context is the explicit stuff, like POS data, sales history and the model's general knowledge of flowers and seasons. Field signals are the expert's observations, each one small and specific and scoped to the part of the system it should change.

I think of HITW as both a pattern and a process. The pattern is the agent architecture, with baseline context, a store of field signals and an engine that merges them when it makes a recommendation. The process is the habit the owner builds. She sees something, sends a sentence about it, confirms what the agent understood and moves on. With the pattern in place, the process is easy enough to happen every week.

How a field signal works

She might text "stop ordering garden roses from that vendor, they're opening too fast," or "everyone's asking for dried pampas again," or "peonies are showing up early at the market this year." The agent turns her message into a structured field signal, and the engine's next round of recommendations reflects it.

Nothing changes until she confirms the signal. After that, the engine blends it with the Clover data, and the recommendations note which signals shaped them.

She can send signals about:

• Vendors she wants to favor or avoid, and for which stems
• The quality of what's arriving
• Flowers that are getting good reviews or being requested at the counter
• Seasonality, when what she sees at the market doesn't match the calendar
• Distribution, when supply or shipping isn't behaving the way the model expects

We keep the signals trustworthy with a few rules:

1. The agent reads every signal back to her in plain language before anything changes.
2. Each signal applies to a specific vendor, stem, season or product rather than the whole system.
3. Signals are dated, so this week's market doesn't steer next spring's orders. Old ones get reviewed or retired.
4. Recommendations cite the signals behind them, so she can see her knowledge being used and correct it if it's off.
5. Every signal goes into a log.

That log ends up being one of the most valuable parts of the build. Over time it becomes the documentation nobody had time to write, in the owner's own words, captured while the knowledge was fresh.

Beyond flowers

Every business has someone whose judgment holds things together, whether that's the owner, a team lead or the person who's been there longest. Most AI projects either leave that person out or hand them a form. Human-in-the-Wild treats them as the best data source in the building and lets them contribute the way they already communicate, with a quick text or email.

This works anywhere you have a forecasting or recommendation problem and an expert who can tell when the numbers are wrong. Think of a restaurant ordering produce, a boutique buying inventory or a contractor scheduling crews.

If your best knowledge lives in one person's head, that's what Wildflower Software builds for. We design AI worker agents for small businesses and enterprises, built alongside the systems you already use. Get in touch and let's talk about what your team knows that your software doesn't.