Three Ways We Actually Use AI in Our Work

Most of the writing about AI in business reads like a press release. Transformative potential, paradigm shifts, the future of work. Very little of it describes what actually happened when someone sat down, picked a model, and wired it into a real system that needed to do a specific thing.

We have been building AI integrations across three different projects over the past year. None of them are chatbots bolted onto a landing page for novelty. Each one solves a particular problem in a particular way, and the three patterns have almost nothing in common with each other except the underlying technology.

A content-aware assistant on our own site

The first integration is the most visible. We added an AI assistant to bluemonkeymakes.com/ask that answers questions about our work, services, case studies, articles, demos. It runs on our own infrastructure and costs nothing in API fees.

The stack: Ollama running Gemma 3 (27B parameters) on our Hetzner servers, with Retrieval Augmented Generation that searches our published content at query time. A custom chat UI built into our Remix app, triggered from the nav.

When someone asks a question, the system searches for the most relevant chunks of our published content and passes those chunks to the model as context. The model generates an answer grounded in what we have actually written, not from its general training data.

The scoping matters. The assistant answers questions about Blue Monkey Makes. It declines off-topic requests. It says "I don't have information about that" when the knowledge base has no relevant content. The graceful decline is deliberate, a scoped assistant that admits its limits is more useful than one that confidently invents answers.

Email classification and composition

The second integration is inside a desktop email client we are building. The problem: email is a mess of conversations, newsletters, notifications, marketing, transactional messages, and calendar invites, all arriving in one undifferentiated stream.

We built a hybrid classification system. A fast, rule-based heuristic classifier handles the cases that have clear signals, domain matching (github.com, shopify.com), sender patterns (noreply@, billing@), subject patterns (receipt, order confirmation), body signals (unsubscribe links, tracking pixels).

The heuristic classifier returns a confidence score. When confidence is high, the classification is final. When it is not, the message gets queued for AI verification.

AI processes uncertain cases in background batches, using whichever provider the user has configured, OpenAI, Anthropic, Ollama, or Open WebUI. Results get cached so the same sender pattern does not require repeated classification.

The philosophy is conservative. The default category is "conversation" unless signals are strong. A newsletter misclassified as a conversation just shows up in the inbox. A real email misclassified as a newsletter might never get seen. False negatives are annoying. False positives lose trust.

The same AI layer handles draft composition with tone selection (professional, casual, formal, concise) and custom instructions. Thread analysis extracts summaries, action items, key dates, and sentiment.

Structured data extraction from facility websites

The third integration is invisible to end users. We are building a senior care search platform, and the core challenge is that facility information, amenities, dining, staffing, pricing, activities, exists on facility websites but in no structured format. Every site is different.

We built an extraction pipeline: scrape the website, clean the content, truncate to fit the context window, extract structured data via Gemma 3 27B with temperature 0.1, validate against Zod schemas, store in the database.

The validation is intentionally lenient. If the model returns "swimming_pool" but the schema expects "pool," the validator filters out the bad value rather than rejecting the entire response. Partial data is better than no data.

Results cache for 30 days on success. The pipeline never overwrites data that a facility provider has manually edited, human input takes precedence. The prompt instructs the model to extract only explicitly stated information, never to infer.

What the three have in common

These are three different systems solving three different problems. But they share a philosophy.

Scoped tasks. None of these systems are general-purpose. Each one does a specific thing with a defined boundary. Narrow scope is what makes them reliable.

Graceful degradation. All three are designed to handle failure without catastrophe. The assistant says "I don't know." The classifier defaults to "conversation." The extraction pipeline accepts partial data.

Self-hosted where it makes sense. Two of the three run entirely on our own infrastructure via Ollama. The email client supports cloud APIs because users need the choice, but Ollama is a first-class option.

AI as augmentation, not replacement. The content assistant augments site navigation. The classifier augments email triage. The extraction pipeline augments data entry. In every case, a human could do the same thing. It would just be slower and harder to scale.

The common thread is restraint

The most useful thing we have learned from building these systems is that AI works best when you are specific about what you need it to do and honest about what it should not try to do.

Every integration that has worked well started with a clear problem, a defined scope, and a plan for what happens when the model gets it wrong. The technology is genuinely capable. But the difference between an AI integration that quietly does its job and one that becomes a liability is almost never about the model. It is about the discipline around it.