When I started building AI-powered tools for education, my instinct was the same one most people have: send the user’s question to Claude, get a response, display it. The AI was the tool. Everything ran through it. And it worked, until it did not. An API key expired over a long break and nobody noticed for a good while. Claude went down occasionally and the tool would with it. And the monthly API bill for what amounted to answering the same twelve questions over and over started to feel like a problem I had created rather than one I had solved.

Over the course of building about half a dozen tools this past year, I gradually arrived at an approach that I wish I had started with. The short version is that the AI should be the finishing layer, not the foundation. The longer version is what this article is about, because the reasoning behind that shift has changed how I think about every tool I build now, and I think it is worth sharing for anyone else working through similar questions.

The Principle: Do the Work Before You Call the API

Every AI API call has a cost. There is the literal financial cost, which for something like Claude’s API is measured in tokens (the chunks of text you send and receive). There is the latency cost, because an API call adds seconds to a user’s experience that a local lookup does not. And there is an environmental cost that is easy to ignore at the scale of a single query but harder to dismiss when you multiply it across a tool that might serve hundreds of users across a district.

Google recently published data showing that a typical AI text query uses about 0.24 watt-hours of energy. Researchers have estimated that a ChatGPT request uses roughly ten times as much electricity as a standard Google search. At the level of a single question, these numbers feel trivial. But when you are building a tool that fields dozens or hundreds of queries a day, the design choice between “send everything to AI” and “send only what needs AI” becomes a meaningful decision about resource use.

The principle I have landed on is straightforward: do as much as possible with structured data and deterministic logic before the AI ever gets involved. If you can answer a question with a keyword match against a curated database, do that. If you can filter a set of strategies down to the relevant ones using the user’s dropdown selections, do that. Save the API call for the part of the task that genuinely requires generative capabilities, the part where the user needs a response that is personalized, synthesized, or contextual in a way that a pre-written answer cannot be.

What This Looks Like in Practice

The clearest example from my own work is the FAQ Chatbot I built for a cooperative’s help desk. The original version of this idea, the one most people would build first, would take every user question and send it to Claude along with the entire FAQ database, letting the AI figure out which answer to return. That works, but it means every single question, including “What are your office hours?” and “How do I reset my password?”, costs tokens, takes seconds, and requires an active internet connection and a valid API key.

The version I actually built uses what I call a hybrid strategy. When a user types a question, the tool first runs keyword matching against a spreadsheet of FAQ entries. Each entry has a set of associated keywords and synonyms, and the matching logic calculates a confidence score based on how much overlap exists between the user’s query and those keyword sets. If the confidence is high enough, the tool returns the pre-written answer immediately. No API call, no latency, no cost.

Only when the keyword matching does not produce a confident result does the tool escalate to AI. And even then, it does not send the entire FAQ database. It sends only the top candidate entries, the ones that scored highest but fell below the confidence threshold, along with the user’s original question. The AI gets a focused context window instead of the whole knowledge base, which means fewer tokens, lower cost, and often a better answer, because the model is working with relevant information rather than sifting through everything.

If no API key is configured at all, the tool works purely on keyword matching. It is less capable in that mode, but it still works. That matters more than most people realize when you are deploying tools to settings where budgets are tight and API subscriptions are not guaranteed to persist.

The Architecture Behind It

Across the tools I have built over the past year, a consistent pattern has emerged that I now use as a starting point for any project where AI is involved. The tool operates in one of three modes, and it selects the mode automatically based on what is available.

In the first mode, when a valid API key is present and the API call succeeds, the user gets the full AI-enhanced experience. The tool has already done the work of filtering and structuring the relevant data, so the AI receives a focused prompt and returns a personalized response. This is the best version of the tool, but it is not the only version.

In the second mode, when the API key is missing or the call fails, the tool falls back to returning the curated content directly. For the behavior intervention tool I built recently, this means the user still gets a filtered set of research-based strategies matched to their specific inputs (grade band, behavior category, framework, setting). They just do not get the AI-generated personalization layer on top. The content is still useful because the underlying database is solid.

In the third mode, the tool returns an error. I use this mode only when showing raw unprocessed data would be confusing or misleading, which in practice is rare. For most educational tools, the curated content is the real value. The AI is adding a polish, not providing the substance.

One design decision that has proven important: when I build a tool for an external organization, I default to having fallback mode turned on. The reason is practical. If the API key expires because someone forgot to renew it, or if billing lapses over the summer, or if a new administrator does not realize the tool depends on an external service, the tool keeps working. It degrades gracefully instead of failing completely. That single configuration choice, which lives in the tool’s config sheet where any administrator can see it, has saved several tools from going dark when organizational circumstances changed.

Sending Less Context, Getting Better Answers

One of the things I have learned through building these tools is that sending less information to the AI often produces better results, not just cheaper ones. This sounds counterintuitive, but the logic is straightforward.

When a user fills out a form in the behavior intervention tool, selecting a grade band, a behavior category, a framework like PBIS or Restorative Practices, and a setting, the tool uses those selections to filter a research base of strategies before the AI ever sees them. Instead of sending 200 strategies and saying “pick the relevant ones,” it sends 15 to 20 strategies that have already been matched to the user’s specific context and says “synthesize these into personalized recommendations.”

The AI’s job becomes synthesis and personalization rather than search and filtering. It is working with material that is already relevant, which means the response is more focused and the prompt is smaller. In terms of tokens, the difference is significant. A prompt with 200 strategies might consume several thousand input tokens. A prompt with 20 pre-filtered strategies might consume a few hundred. Over hundreds of uses, that difference adds up in both cost and environmental impact.

This pattern applies beyond my specific tools. Anytime you are building something that sends a knowledge base to an AI, ask whether you can filter that knowledge base first using deterministic methods. Dropdown selections, keyword matching, categorical filters, date ranges, any structured data that narrows the field before the AI call is reducing your footprint without reducing your quality. In many cases, it is improving quality by removing noise.

Pre-Built Responses and Canned Content

Not every response needs to be generated. This is another area where the instinct to use AI for everything creates unnecessary overhead.

In several of my tools, there are response paths that are entirely pre-written. If the FAQ Chatbot matches a question with high confidence, it returns the human-authored answer from the spreadsheet verbatim. No AI involvement at all. The answer was written once by someone who understood the question, reviewed for accuracy, and stored in a format that can be updated by anyone with access to the sheet.

For the behavior intervention tool, the fallback mode returns strategies directly from the curated research base. These are not AI-generated summaries. They are descriptions written by people with expertise in the relevant frameworks, stored in a spreadsheet, and returned as structured content. The AI, when it is available, adds a layer of personalization and synthesis on top of that content, but the content itself stands on its own.

There is an important pedagogical point here too. In educational contexts, curated content from known sources often carries more weight than AI-generated text, especially with administrators and teachers who are (reasonably) cautious about AI accuracy. A tool that returns “here are four research-based strategies from the PBIS framework for addressing off-task behavior in elementary settings” with citations and descriptions is providing something concrete and verifiable. The AI layer can make that presentation more conversational and more specific to the user’s described situation, but the foundation does not depend on it.

PII and Local Processing

One more area where doing work locally instead of sending it to an AI makes both practical and ethical sense: personally identifiable information.

The behavior intervention tool accepts free-text descriptions of student behavior. Those descriptions could, intentionally or accidentally, include student names, ID numbers, or other identifying information. The tool runs a local PII detection check using regex pattern matching before anything gets sent to an API. If potential PII is detected, the user gets a warning and a chance to edit their text. The tool never stores the free-text fields regardless of the outcome.

Could I send the text to AI for more sophisticated PII detection? Technically, yes. But that would mean sending potentially sensitive student information to an external API in order to determine whether it contains sensitive student information. The simpler local approach, even with its false positives (numbers that look like student IDs, patterns that look like dates), is a better fit for the context. It keeps student data within the user’s own Google Workspace, and the warning-rather-than-blocking approach means false positives do not prevent people from using the tool.

This is a small example of a larger principle: not everything that AI can do is something AI should do in a given context. Especially in education, where data privacy is both a legal obligation and a trust issue, the question of whether a task requires sending data to an external service deserves deliberate consideration rather than automatic escalation.

A Practical Checklist

For anyone building tools that incorporate AI, here is the set of questions I now ask during the planning phase, before any code gets written.

• Can the core function of this tool work without AI at all? If the answer is no, consider whether you are building an AI tool or a tool that uses AI. The distinction matters for reliability, cost, and accessibility.
• What data can be filtered or structured before the AI call? Every dropdown selection, keyword match, or categorical filter that narrows the context is reducing your token usage and often improving your results.
• Are there responses that can be pre-written instead of generated? For FAQ-style questions, common recommendations, or standard informational content, human-authored responses stored in a spreadsheet are faster, cheaper, more reliable, and often more trustworthy than generating them fresh each time.
• What happens when the API is unavailable? Whether that means the key expired, the service is down, or the user does not have internet, your tool should have a plan that is not “show an error message.” Graceful degradation is not a nice-to-have. For tools deployed to real educational settings, it is a design requirement.
• Does this data need to leave the user’s environment? For anything involving student information, the default should be local processing unless there is a clear reason to send it externally, and that reason should be weighed against the privacy implications.

Why This Matters Beyond Cost

I want to be clear that the argument here is not primarily about saving money on API credits, although that matters, especially for districts and cooperatives operating on tight budgets. The deeper argument is about building technology that is sustainable, reliable, and appropriate for the contexts where it will be used.

A tool that requires a constant internet connection, a valid API subscription, and an external service to be operational is a tool that is fragile in exactly the ways that matter most for rural and under-resourced educational settings. A tool that uses AI thoughtfully, as an enhancement layer on top of solid local functionality, is a tool that keeps working when circumstances change. And in education, circumstances always change.

There is also an alignment question that I think is worth sitting with. If we believe that AI should serve learning rather than the other way around, then designing tools that depend on AI as little as possible while using it as effectively as possible is a coherent expression of that belief. The goal is not to avoid AI. The goal is to use it where it genuinely adds value and to do everything else with simpler, more transparent, more controllable methods.

If you are building tools like this, or thinking about starting, I would enjoy hearing about your approach. What problems are you solving, and where have you drawn the line between what AI handles and what your tool handles on its own? You can reach me at licht.education@gmail.com, and there are more tools, articles, and resources at bradylicht.com.