# David Edwards > David Edwards is the AI Strategist at Colorado State University. He turns "we should do something with AI" into systems people actually use, and the governance and adoption that make them stick. Canonical site: https://davidedwards.ai # Projects --- ## David's Brain > A self-hosted memory system that every AI assistant I use shares. Claude, ChatGPT, and my own agents all read and write the same brain. Mine. Canonical: https://davidedwards.ai/projects/davids-brain/ ## The problem Every AI assistant has amnesia. I'd tell Claude about a project on Monday, and on Tuesday ChatGPT would ask me to explain the whole thing from scratch. The vendors all offer memory features now, but each one is a separate silo, you can't really see what's in them, and none of it comes with you when you switch tools. Meanwhile, I already write everything down. Meeting notes, project docs, daily logs, all in Obsidian. The information existed. The assistants just couldn't see it. The jumping-off point was Nate B. Jones's [Second Brain](https://natesnewsletter.substack.com/p/bridge-the-ai-implementation-gap) writeup, arguing the AI implementation gap closes when your own knowledge base becomes queryable by any model. I took that idea and built the version that fits how I actually work. ## What I built Three pieces: - **A Postgres database with pgvector** that stores quick captured thoughts and makes everything searchable by meaning, not just keywords. - **An indexer** that watches my Obsidian vault and keeps every note embedded and current. - **An MCP server** that exposes it all as tools: search my memory, save a thought, read or edit a note, append to today's log. If MCP is new to you, here's the short version: it's a standard protocol that lets AI assistants plug into outside systems, like USB for AI tools. Because David's Brain speaks MCP, the same memory connects to Claude Desktop, Claude Code, ChatGPT, and my own automation agents. Ask any of them "what did I decide about X?" and they all query the same store. Tell any of them "remember this" and it lands in the same place. (Yes, it's called David's Brain. Naming things is hard, and at least this one is accurate.) ## Why you might care If you use AI assistants at all, you've felt this: re-explaining your context to every tool, every session. This project is that position expressed in code: the memory should belong to you, not the vendor. Assistants come and go. The knowledge base persists. When a better model ships next month, I point it at my brain and it knows me on day one. ## Notes for the technical crowd - Tool descriptions are UX. The difference between an assistant that uses memory well and one that ignores it is almost entirely in how the MCP tools describe themselves. - Semantic search alone isn't enough. Structured metadata (people, projects, note types) does the heavy lifting for real queries like "what did Josh and I decide last week?" - If capture isn't frictionless, you stop capturing, and a memory system you don't trust is worse than none. Speed and reliability are the whole product, not a polish layer on top. --- ## CSU AI Gateway > A self-service portal that gets university researchers API access to frontier AI models, with hard budget caps and automatic chargeback billing. A vending machine for API keys, minus the surprise invoices. Canonical: https://davidedwards.ai/projects/csu-ai-gateway/ ## The problem Researchers at Colorado State wanted API access to models like Claude and GPT-4 for their work. The official path ran through Azure AI Foundry, which is powerful and also about as approachable as a tax form. The unofficial path was personal API keys on personal cards, which meant unmanaged spend and research data flowing outside the university's data agreements. Neither of those is a plan. So we built one. ## What I built From a researcher's point of view, four steps: 1. Request access on a web portal, using your normal university login. 2. An admin approves it. 3. You get an OpenAI-compatible API key with a hard monthly dollar cap. 4. Your usage is metered and billed back to your grant account automatically. That's it. No cloud console, no procurement adventure, no P-card. Under the hood: a FastAPI backend drives [LiteLLM](https://litellm.ai) as the metering and routing engine, sitting in front of Azure AI Foundry and Azure OpenAI. LiteLLM owns token counting, budget enforcement, and key management. The portal owns approvals, the model catalog, and billing export. ## Design decisions I'd defend - **Hard caps, not alerts.** A runaway script hits its cap and stops. Nobody discovers a horrifying invoice at the end of the month, which in a university is the difference between a program and a cautionary tale. - **No raw key storage.** Keys are shown once at creation. We keep an alias and a masked value, nothing that can leak. - **Enterprise data terms by default.** Prompts through the gateway are covered by the university's agreement with Microsoft, so research data isn't used to train models. Researchers get that protection without having to read a single terms-of-service page. - **Runtime model management.** A new model shows up, an admin prices it, it's live. No redeploy, no maintenance window. ## Why you might care The real lesson is the pattern, not the plumbing: **make the sanctioned path easier than the workaround, and compliance happens on its own.** People weren't using personal API keys to be rebels; they were using them because the official route was painful. Fix the pain and governance mostly takes care of itself. Nearly every institutional AI question I get turns out to be some version of this problem. --- ## AI Strategy & Governance > The half of the job that doesn't fit in a repo: governance that makes real decisions, guidance people actually follow, and enough allies that adoption doesn't depend on one person. Canonical: https://davidedwards.ai/projects/ai-strategy-governance/ ## The work Half of what I do produces code. The other half produces decisions, and the second half is harder. As CSU's AI Strategist I'm the person in the room when a data governance committee has to rule on AI access to chat histories, when legal counsel and a vendor's documentation disagree about where data actually goes, or when a dean wants to know whether a tool is safe before ten thousand students touch it. None of that ships as software. All of it determines whether the software matters. ## Governance that actually decides things Most governance committees are performative. They discuss vague topics, produce no decisions, and everyone leaves with the same questions they arrived with. The fix I've landed on is treating governance like product work: show up with a specific problem, a concrete proposal, and a genuine decision to be made. Committees are surprisingly good at deciding when you give them something decidable. That approach has turned our data governance process from a place where AI questions went to stall into the mechanism that unblocks them: real rulings on agent data access, AI evaluation built into software procurement, and clear ownership of the questions that used to float. ## Rules people can follow "Can I use this AI tool with this data?" sounds like one question. It's three: what does the law require, where does the data physically go, and what do the privacy settings actually guarantee. I wrote up the worked example in [the Microsoft Foundry Claude case](/writing/what-the-microsoft-foundry-claude-question-actually-taught-us/), where the comfortable assumption ("it's Microsoft, it's covered") turned out to be wrong in ways that mattered. The output isn't a memo. It's a system: AI tools mapped against the data classification levels the university already uses, a vetting checklist so the analysis is repeatable, and a data steward as the approval gate instead of individual guesswork. Boring on purpose. Boring is what catches problems before they become incidents. ## Adoption that scales past one person One strategist cannot personally drive AI adoption across a research university, and pretending otherwise is how these roles fail. So a good chunk of my time goes into people: a growing network of AI-curious champions across colleges and divisions who advocate and teach where I can't be, leadership briefings that build fluency instead of dependence, and a standing policy of meeting people where they are. Help the willing. Don't evangelize the resistant. Some people will never adopt, and that's fine. ## Why you might care If you're the "AI person" at your institution, the technology is the easy half, and it's the half everyone wants to talk about. The durable work is institutional: getting committees to decide, turning legal ambiguity into usable rules, and building enough distributed capability that progress survives you leaving the room. That's the part I'd compare notes on first. --- ## OpenAlex MCP Server > An MCP server that lets campus AI agents query the OpenAlex scholarly database live, instead of guessing from documents somebody uploaded last semester. Canonical: https://davidedwards.ai/projects/openalex-mcp/ ## The problem Campus AI agents usually answer from documents you upload into them, and research data goes stale the moment you snapshot it. "What has this faculty member published recently?" is a question with a moving answer. The data already lives in [OpenAlex](https://openalex.org), a free, open catalog of scholarly publications. The agents just needed a way to ask. ## What I built An MCP server that turns OpenAlex queries into tools an agent can call: search publications, look up authors, explore an institution's research output. Any MCP-capable agent platform can attach it and answer research questions with live data and real citations, instead of confidently summarizing a PDF from two years ago. It runs as an Azure Container App with scale-to-zero, which means it costs nothing while idle and wakes up when called. For a university watching every AI dollar, "free while nobody's using it" is the right default for this kind of infrastructure. ## Why you might care This project earned its keep as a demo. MCP is abstract until you watch an agent pull a live publication list mid-conversation; then it clicks for everyone in the room. A small, cheap, working example beat every slide deck I could have made, and it became the template (architecture, hosting model, and pitch) for the MCP servers that came after it, including the ones I've helped other campus teams build. If you're trying to sell an organization on agent-to-system integration, my advice is the same: skip the strategy document, ship the smallest possible live example, and let it do the talking. --- ## Campus AI Agents > Production knowledge agents for university teams, and the method that keeps them answering accurately instead of confidently. Canonical: https://davidedwards.ai/projects/campus-agents/ ## The work As CSU's AI Strategist I steward the university's agent platform and help teams across campus ship agents that actually work: student-facing assistants, departmental knowledge agents, and specialized tools for groups like learning design and graduate teaching support. The stakes are real. An agent that makes up tuition numbers isn't funny, it's potentially a legal problem with a phone number attached. So the method that keeps dozens of them trustworthy matters more than any single agent. ## The method - **Knowledge is designed, not dumped.** Raw transcripts and PDFs get pre-processed into structured Markdown (clean topics, consistent headings, explicit policy language) before they ever reach a knowledge base. Most retrieval quality is determined before retrieval happens. - **Agents get tools, not just documents.** Where live data matters, agents call MCP servers instead of reading snapshots. The [OpenAlex server](/projects/openalex-mcp/) is the template. - **Local teams own their agents.** The sustainable model is distributed: each unit maintains its own agent and knowledge, with central governance and shared patterns keeping quality up. One central team maintaining fifty agents is a bottleneck with extra steps. - **Guardrails are mostly content work.** When an agent says something wrong, the cause is usually ambiguous source material, not model misbehavior. Fixing the corpus beats fighting the prompt, almost every time. ## Why you might care The demo is the easy part. Anyone can wire up a chatbot over a folder of PDFs in an afternoon, and it will look great in the meeting. Getting agents into production across a decentralized institution, with real owners, real governance, and answers you can defend to a dean, is an organizational design problem wearing a technology costume. That's the problem I actually work on, and the four practices above are what's survived contact with reality so far. # Writing --- ## Jev, and the cost of a decision > TypeSafe's Jev returns typed decisions instead of text for $0.042 per million input tokens. What matters for agents is what becomes affordable to ask once a judgment costs almost nothing. Published: 2026-09-21 · Canonical: https://davidedwards.ai/writing/jev-and-the-cost-of-a-decision/ TypeSafe AI shipped a model last week that cannot write a sentence. It cannot write code, summarize a document, or explain its own reasoning. You hand it a description of a situation and a set of typed questions, and it hands back answers with probabilities. I have spent more time thinking about that than about anything else that shipped this month. Most of the writeups file Jev under "classifier," which is accurate and also the least interesting thing about it. Classification is the shape of the output. What matters to me is the price of the output, and what that price makes affordable inside an agent loop, where I have been paying frontier rates to ask questions that are not frontier questions. For anyone new to this: a normal language model writes its answer one word at a time. That is why asking "is this email about billing?" costs about the same as asking for a paragraph of advice. Jev never generates text. It samples every answer in a single pass and returns a value constrained to the options you defined in advance. If you have ever written an `if` statement that needed to understand meaning, this is a model built for exactly that spot in the code. Some background. TypeSafe came out of two years in stealth on September 15 with $40M led by DCVC. The founder, Diogo Almeida, was an author on the InstructGPT paper, the research that turned instruction-following language models into products. He has spent the launch explaining that chat is the wrong interface for software, because software does not want a paragraph, it wants a value. Jev is named after William Stanley Jevons, who noticed that making steam engines more efficient increased coal consumption rather than reducing it. The bet is that cheap decisions get made in places nobody would have paid for a model call. ## What Jev actually is You send two things, `state` and `questions`. The state is the situation. It can be a plain string, a JSON object with named fields, or a list of text for a conversation. Text only, no images or audio. The questions are what you want to know about that state, and each one declares its own shape. There are three types, and the entire API is those three. | Type | The question you write | What comes back | |------|----------------------|-----------------| | Noul | Is this true? | A single probability from 0 to 1 | | Choice | Which of these options? | The selected option, the full distribution, a confidence | | Score | Where on this scale? | A position that can land between levels, plus distribution and confidence | A Choice takes up to 255 options. A Score takes two to ten ordered levels. Every answer comes back in roughly 70 to 500 milliseconds, with most landing near 100. Input tokens cost $0.042 per million and output tokens are free, which sounds wrong until you remember there is almost no output to meter. All the questions run in parallel against the same state. Adding a tenth question costs a few tokens and essentially no time, which inverts the usual instinct to ask one cheap question first and follow up only if needed. You ask everything up front and let your code decide which answers were relevant. TypeSafe trained Jev with a method it calls Reinforcement Learning for Calibrated Decisions. The load-bearing word there is calibrated: across many predictions, the answers it gives 90% confidence to should be right about 90% of the time. Chat models are trained to produce answers humans rate highly, and they are reliably overconfident when you ask them for a probability. If a model is right 95% of the time but cannot tell you which 5% it is unsure about, you cannot safely automate the task. Calibration is the difference between a model you consult and a model you wire into a decision. ## What Jev cannot do It does not generate anything. No prose, no code, no summaries. If you need text, you still need an LLM, and the useful architecture is the two of them together. It is not a calculator. It does not count reliably, and the error grows with the size of what you are counting. Dates are text to it, not ordered quantities, so "which of these came first" and "is this inside the window" are both unreliable. Extraction is judgment and Jev can do it. Assembly, ordering, and arithmetic are computation, and that stays in your code. It gives you a number, not a rationale. That is fine for routing a support ticket and a problem for anything an auditor will read. It reads literally. It answers the question you wrote, not the one you meant. The tell is when you look at a wrong answer and start explaining what you really meant, because that explanation was the missing half of your instruction. The state is also not treated as hostile. Text engineered to argue for its own classification can move the answer. If user-controlled content goes into the state, that is your threat model to own. ## Pros and cons against an LLM The honest version of the comparison, with the caveat that most of the numbers come from TypeSafe's own benchmarks. Where it wins: - **Cost:** $0.042 per million input tokens against $0.20 to $10 for frontier models, with free output. That is somewhere between 5 and 238 times cheaper on input depending on what you compare to, and the workflow evals they published claim a 444x reduction on their own workloads. - **Latency:** 70 to 500 milliseconds against 3 to 329 seconds for frontier models on the same class of question. A router that adds a second is a different product from one that adds 100 milliseconds. - **No type errors:** The output cannot be a value outside the schema you defined. That is structurally impossible rather than statistically unlikely, so your parsing and validation code can go away. - **Confidence with every answer:** You set a different threshold per action. Approve a transfer above 0.85, show a balance above 0.5, send anything murkier to a human. - **Many decisions per round trip:** Ten questions in one call beat ten calls. Where it loses: - **It cannot produce text:** Anything generative stays with the LLM. This is a complement, not a replacement, and the launch-day projects all treat it that way. - **No rationale:** A probability is not an explanation. - **It cannot compute:** Counting and date math have to be rebuilt as deterministic code around it. Dates are the absolute worst. - **"Cannot hallucinate" is narrower than it sounds:** Jev cannot return an invalid answer. It can return a **wrong** valid one, with a confident probability attached. - **Context rot applies:** Accuracy falls as the state fills with material the question does not need. Whatever assembles the state decides what Jev is allowed to know, and padding it costs you accuracy before it costs you money. - **The price might be subsidized:** TypeSafe says so itself, and says it expects the number to fall rather than rise. YMMV. ## What I actually want to do with it This is where my thinking has gone, and none of it involves classification. ### 1. Route work to the cheapest model that can do it I do this by hand right now. Straightforward tasks go to a small model, anything needing real reasoning goes to a bigger one, and the decision is mine. The problem is that I have to make it before I know what the task is, so the safe answer is usually the expensive model. A Jev call in front of that turns it into a graded decision. Send the request, ask how much reasoning it needs and which profile it matches, and pick the tier from the answer. The pattern is well studied outside of Jev: RouteLLM reported sending only 14% of queries to the strong model while keeping 95% of the quality, and FrugalGPT's cascade reported large reductions by letting cheap models handle the easy majority. The research version needed training data and a purpose-built router. A model that takes runtime questions and returns calibrated probabilities is a much smaller thing to maintain. Getting the routing right is easy next to getting the thresholds right, and thresholds are the part I expect to spend real time on. ### 2. Decide which skills and MCP servers get loaded This is the one I think about most, because it is the largest number on my own invoice. My chats open around $0.18 before the agent has done anything at all, and most of that is context. Tool definitions are not free. Fifty MCP tools run to roughly 72,000 tokens of schema before any work starts, and a couple of servers attached to an agent can put 30,000 tokens of metadata in the window. Anthropic's own numbers show a dynamic approach landing around 8.7K tokens where a static one took 77K. This is a documented cost, and the usual fix is a search or ranking layer over the tool catalog. What Jev adds is the ability to ask the question in your own words. Send it the prompt plus the names and descriptions of your skills and servers, not their contents, and ask which ones this task needs. At $0.042 per million tokens, reading 5,000 tokens of catalog costs about two hundredths of a cent. A hundred of those a day is sixty cents a month. If it reliably keeps two unneeded servers out of the window, it pays for itself on the first turn. The reason to slow down: this saves money only where the gated context is genuinely optional. If most of that $0.18 is system prompt, conversation history, and tools the task really does need, the gate shrinks the easy slice and adds a network call. Measure which slice you are cutting before you get excited about the percentage. ### 3. Decide whether a job should run at all I have cron jobs that check the news, triage mail, and assemble a morning brief. Right now the "should I run today?" logic is Python I wrote by hand, checking for new items and quiet days. It works, and it is brittle in the way hand-written logic always is: I wrote conditions for the cases I thought of, and the interesting days are the ones I did not think of. A decision model in front of a job is a better fit, and it composes. Should this run at all. Is this item material enough to include. Does this deserve the expensive model or a summary. Those are three questions in one call, and the answers arrive before the job has spent anything. ### Other places I think this fits Beyond those three, the pattern I keep finding is that agents are full of small judgments currently made by an expensive model, by brittle code, or by nobody. - **Gating a tool call before it executes:** is this command read-only, reversible, or destructive? Coding agents ship some version of this internally, and it has been closed source until now. An open, cheap classifier in that spot changes how much you can let an agent do unattended. - **Deciding the loop is finished:** most agents stop because the model said so. Asking a separate model whether the task is actually complete, against the original request, is a second opinion you can afford on every turn. - **Deciding what deserves to be remembered:** every memory write is a judgment about future relevance, usually made by the same model doing the work. Whether a fact is worth persisting, and how durable it is, is a bounded question. - **Deciding whether to interrupt a human:** is this worth a notification, or does it keep until the digest? That is the difference between an agent people keep and one they mute. ## What I would be careful about Cheap decisions are still decisions, and a cheap wrong one at the front of a pipeline is more expensive than an expensive right one. Two things I would hold onto. Price the failure before you pick the threshold. Confidence of 0.7 is plenty for tagging a document and nowhere near enough for moving money. TypeSafe's own framing is that you set the bar per action, and that only works if you have priced the failure. Log before you act. Run it in shadow mode for a week, record the confidence and what you would have done by hand, and only then let it into the pipeline. The launch-week projects that will still be running in six months are the ones doing this. One more thing, from the design guidance in the docs that holds up regardless of Jev: avoid asking a model something code can compute exactly, and avoid hiding several judgments inside one question. Most of my bad prompts fail the second one. "How good is this candidate" is four judgments wearing a trenchcoat, and splitting it into four questions with weights I control turns an opinion into something I can tune. ## Where this lands Jev is interesting because it makes a category of decision free enough that you stop rationing it. My agent currently decides what to load, which model to use, and whether to do the work at all, and it makes those calls with the most expensive tool available, or with Python I wrote on a Tuesday. A decision that costs a fraction of a cent and 100 milliseconds is a decision you can afford to make well. That is the part I have been poring over. The practical caution is that it is early. Waitlist, one provider, self-reported benchmarks, and a price that might be a subsidy. If you want to try the shape of it today without the waitlist, a small local model behind a strict output schema gets you most of the interface, minus the calibration. If you want the calibration and the latency, the pattern to copy is the boring one: put the smart `if` statement in front of the expensive call, log everything for a week, and let it earn the right to act. --- ## The model is part of the product > AI companies have good reasons to route work to cheaper models. Paying customers still deserve to know when the product underneath their subscription changes. Published: 2026-09-05 · Canonical: https://davidedwards.ai/writing/the-model-is-part-of-the-product/ Microsoft has started using its own AI models for some requests in Excel and Outlook. According to [Bloomberg](https://www.bloomberg.com/news/articles/2026-07-07/microsoft-replaces-openai-anthropic-with-own-ai-in-some-apps), its MAI models are now handling tens of thousands of prompts each week that previously would have relied more heavily on models from OpenAI or Anthropic. The new models still handle a small fraction of total requests, and Microsoft has not announced that it is removing Claude or OpenAI models from Microsoft 365 Copilot. This is an incremental shift in how Microsoft runs the service, not evidence that the model picker is about to disappear. Still, I think enterprise customers should pay attention. Microsoft has been explicit about wanting to reduce what it spends on third-party models. That is a rational business goal. Anthropic and OpenAI charge for inference, Microsoft operates Copilot at a scale few companies can match, and every prompt carries a cost. If Microsoft's own models can handle a task well enough for less money, routing some work to them makes sense. The customer problem begins when "well enough" is decided entirely by the vendor, the substitution is difficult to see, and the subscription price stays the same. ## Why model choice matters It is tempting to treat models as interchangeable infrastructure. Most people do not care which database answers a query or which server processes an email. Why should they care which language model writes a paragraph or analyzes a spreadsheet? Because the differences are still visible in the work. Models vary in reasoning, writing, instruction-following, coding, tool use, and how they handle long or ambiguous tasks. A cheaper model may be perfectly adequate for summarizing a routine email. The same substitution can become obvious when the task is reconciling a complicated spreadsheet, editing a sensitive document, or following a long set of constraints without wandering off halfway through. I see this in my own evaluations. Access to Claude inside Microsoft 365, especially in Excel, is one of the strongest reasons I can give someone to pay for the upgraded Copilot license. It puts a capable model inside the tool where the work already lives, with Microsoft's identity, administration, and enterprise protections around it. That combination is useful. Microsoft has promoted that choice too. When it announced Anthropic support in Microsoft 365 Copilot, it described the move as giving customers the flexibility to use different models and choose the right tool without jumping between platforms. That was not a minor implementation detail. It was part of the value proposition. If customers subscribe partly because that choice exists, replacing it with an opaque routing decision changes the product even if the name and monthly price remain untouched. ## The uncomfortable economics of flat-rate AI I don't expect Microsoft, or any other company, to provide unlimited access to the most expensive models forever at a fixed monthly price. The economics are ugly. Traditional software subscriptions work because the marginal cost of one more active user is usually small. AI subscriptions are different. Every request consumes compute, and a complicated agent can make many model calls before it produces one visible answer. The heaviest users can consume far more than their subscription fee. Vendors have a limited set of responses. They can raise prices, impose usage caps, move customers to metered billing, route more work to cheaper models, or subsidize the difference and hope inference costs fall quickly enough to rescue the spreadsheet. Most are experimenting with several of those options at once. OpenAI tried to simplify ChatGPT by making GPT-5 a unified system with a router that decided when a request needed deeper reasoning. At launch, it also removed access to several older models. Paid users objected, in part because they had learned which models worked best for different tasks. OpenAI [restored the model picker and legacy model access](https://techcrunch.com/2025/08/12/chatgpts-model-picker-is-back-and-its-complicated) within days. Cursor changed its $20 Pro plan from a request allowance to $20 of frontier-model usage at API prices. Unlimited use remained available through Auto, where Cursor chooses the model. The company later [apologized for communicating the change poorly](https://cursor.com/blog/june-2025-pricing), acknowledged that it had surprised customers, and offered refunds for unexpected charges. GitHub Copilot is taking the metering route. Starting in June 2026, premium requests are being replaced with [GitHub AI Credits](https://github.blog/news-insights/company-news/github-copilot-is-moving-to-usage-based-billing), calculated from token use and each model's published API price. This is more transparent than invisible substitution, but it also makes clear that access to expensive models is becoming a metered resource rather than a simple benefit of having a seat. Anthropic is wrestling with the same problem from the other side. In April, it tested removing Claude Code from the $20 Pro plan for about two percent of new subscribers. Anthropic reversed the public-facing change after users noticed, but its head of growth acknowledged that the plans were created before long-running agents became an everyday use case. [Those subscriptions were not designed for current usage patterns](https://arstechnica.com/ai/2026/04/anthropic-tested-removing-claude-code-from-the-pro-plan). None of these companies is uniquely villainous. They are discovering that flat-rate subscriptions and variable inference costs make uncomfortable roommates. But the pattern matters. The market is moving from "pay for access to these models" toward "pay for an AI service that decides how much intelligence each task receives." That may be a workable product. It is not the same product. ## Where Microsoft deserves some room Microsoft has legitimate reasons to build and use its own models beyond saving money. Owning more of the model stack can reduce dependency on suppliers that are also competitors. It can improve capacity planning. Smaller models can respond faster and use less energy. A model trained for a narrow Office task may outperform a larger general-purpose model on that specific task. Data residency and contractual requirements can also affect which provider is appropriate for a customer or region. And bigger is not automatically better. I routinely use less expensive models for straightforward work and save the strongest ones for architecture, difficult analysis, and tasks where mistakes are costly. Deepseek V4.1 Flash, in particular, is roughly Sonnet-level for most of my agentic workflow. At an order of magnitude less price. Sensible routing can give users faster answers while preserving expensive capacity for the work that needs it. I would welcome that kind of routing inside Copilot if customers could inspect it and override it. The concern is not that Microsoft uses Microsoft models. What worries me is that model substitution could become an invisible way to reduce the cost of serving a paid customer without giving that customer a way to tell whether quality changed. That concern is sharper because Copilot is sold as more than a chat box. Organizations make adoption plans around it. They train people. They review data protections, remediate oversharing, assign licenses, and decide which other tools they no longer need. The cost of a quiet model change is not limited to one disappointing answer. It can affect the case an organization made for the product in the first place. ## What enterprise buyers should ask for The answer is not a contractual promise that one named model will remain available forever. Models improve, providers retire old versions, and a frozen model catalog would become its own problem. Enterprise customers need a clearer operating agreement around change. Vendors should identify which model handled a request, especially when automatic routing is enabled. Customers should be able to choose a specific model for work where provenance or capability matters. Material changes to model access, routing behavior, or included usage should come with advance notice. If a premium model becomes a metered add-on, the pricing should be visible before someone builds a workflow around it. Organizations also need to stop evaluating AI products as if the interface were the product. Procurement and governance reviews should ask: - Which models are available today, and which are guaranteed by the agreement? - When can the vendor substitute another model without notice? - Can users or administrators require a specific model for a workflow? - Is the model that processed a request visible in logs or usage reports? - What happens to price and functionality when a third-party model becomes more expensive or unavailable? - How will the vendor communicate a material change? Those questions are not anti-Microsoft. They are what responsible customers should ask any AI vendor, including Anthropic, OpenAI, Google, Cursor, and the dozens of products packaging those models behind their own interface. ## Partnership should allow an honest question Microsoft is an important partner to my institution. I want its AI products to improve, and I want the partnership to work. I also think good partnerships have room for customers to say when a product decision could undermine trust. Microsoft may build a model that matches or exceeds Claude for the work people do in Office. If it does, the case for using it will be easy to make. Show customers the results, expose the model choice, explain the economics, and let organizations decide how much control they need. What would bother me is paying the same premium price for a product sold partly on access to advanced third-party models, then discovering that the expensive model had become an occasional upgrade behind a cheaper default. The invoice would say nothing changed. The product would say otherwise. AI companies need sustainable economics. Customers need predictable value. The companies that handle this well will not be the ones that avoid changing their products. They will be the ones that make those changes visible, explain the tradeoffs, and give paying customers a meaningful choice. --- ## Responsible AI governance should create safe paths to yes > Good AI governance does more than say no to risky tools. It gives people a safe way to do the work they were going to do anyway. Published: 2026-07-27 · Canonical: https://davidedwards.ai/writing/responsible-ai-governance-should-create-safe-paths-to-yes/ If your AI governance program gives people only two choices, broad access or "no," it is not governing adoption. It is outsourcing adoption to whichever tool gets invited to the next meeting first. That sounds harsh, but department leaders know the pattern. Someone sees a meeting bot produce a transcript and action items they can actually use. They have meetings all day. Their notes are scattered. The bot solves a problem in front of them. Then IT or legal says the tool has not been approved. The leader hears: "You cannot have the thing that makes this work easier." They may comply for a while. Or they may use a personal account, ask a colleague to add the bot, or stop telling anyone. None of those outcomes improves the institution's security posture. Good governance creates a usable, bounded path to yes. ## Start with the work people are trying to do A surprising amount of AI governance starts with the product name. Is this vendor approved? Is that model allowed? Does this bot have the right certification? Those questions matter, but they are not where department leaders begin. They begin with work: capture a meeting, summarize a long document, help a team find the decision they made three weeks ago, or give a researcher a controlled way to use a model. If a third-party meeting bot is showing up in your Teams meetings, that is not only a vendor-management problem. It is evidence that people need better meeting capture and follow-through. In a Microsoft environment, Teams Premium can meet much of that need. It provides transcription, recap, notes, and action items inside a platform the institution already manages. Teams Premium is not perfect, and transcription is not appropriate for every meeting. But it gives people an option that works under agreements, identity controls, retention practices, and support structures they already understand. A policy that says "do not use unapproved meeting bots" is incomplete. A better policy says, "Use Teams Premium for this class of work. Here is how to request it. Here are the meetings where transcription should be off. Here is who can help when the default does not fit." That is governance people can follow. ## Agreements are part of the product The other mistake is assuming that a familiar delivery method means familiar terms. Microsoft offers its own models, OpenAI models, and Anthropic models through related enterprise services. From a department leader's perspective, they may all look like they come through the same front door: Microsoft identity, Microsoft billing, Microsoft infrastructure, perhaps Azure AI Foundry. That is useful, but it does not make the underlying data terms identical. A Microsoft enterprise agreement can provide important protections around identity, infrastructure, billing, and the Microsoft services it covers. It does not automatically make every partner model subject to the same data-processing terms. Who processes prompts and completions? Is data retained? Can a provider use a human review process for flagged content? Is zero retention a setting, a contract addendum, or unavailable for a specific model? Those are not fussy procurement details. They determine what data a department can safely put into a tool. I wrote more about that distinction in [the Microsoft Foundry Claude question](/writing/what-the-microsoft-foundry-claude-question-actually-taught-us/). The short version: "it is delivered through Microsoft" and "it is covered by Microsoft's agreement in the way we need" are different claims. Treat them that way. Before you call an AI product approved, identify the agreement that applies to the actual model and deployment. Do not stop at the logo on the portal. ## Use pilots to learn without opening every door A bounded pilot gives you a practical option between universal access and blanket restriction. Give a small group access to a specific capability, document what it can reach, name the owner responsible for it, and inspect what happens. Then expand, change the controls, or stop. We are using that pattern with M365 integration for NebulaOne. The integration makes an agent more useful because it can work with the systems where people already keep documents and conversations. It can also surface permission problems that have been sitting in shared drives and Teams sites. Those permissions already existed. AI makes the consequences easier to see. We are enabling the integration for a smaller group first and asking them to look for security issues, unexpected access patterns, and bad assumptions before the capability reaches a broader audience. The testers are there to find problems, not to ceremonially approve a decision someone else already made. That beats a diffuse process where everyone can veto and nobody owns the next step. A good pilot has a few plain rules: - State the specific job the capability is meant to help with. - Limit the data, permissions, and tester group to what the pilot needs. - Give one person authority to make the next decision. - Decide what evidence would justify expanding access, changing the configuration, or shutting it down. - Tell participants what they can and cannot put into the tool while the pilot is running. Now you have evidence instead of a meeting about evidence. ## A short checklist for department leaders When a department asks whether it can use an AI tool, I start here: 1. **What work are we trying to improve?** Name the task before debating the product. 2. **Is there already an approved option that covers most of it?** If there is, make that option easy to get and support. 3. **What can this tool actually access?** Include files, email, Teams content, meeting recordings, and connected systems, not only the text pasted into a prompt. 4. **Which agreement governs this exact product, model, and deployment?** "Enterprise" is not a complete answer. 5. **What data belongs nowhere near it?** Write this down in language a department can use. 6. **Can we test it with a limited group first?** Start with willing participants and narrow permissions. 7. **Who owns the next decision?** Pilots without an owner become permanent limbo, which is governance's least useful habitat. The goal is to prevent the predictable split between people who need to get work done and people tasked with protecting the institution. When governance gives people a credible option, clear boundaries, and a way to ask for more, it earns trust. When it gives them only a no, it should not be surprised when the bot joins the meeting anyway. --- ## What the CPR Summit taught me about AI and compliance > A room full of compliance professionals. A show of hands. And a gap between what AI can do and what's actually being used. Published: 2026-07-24 · Canonical: https://davidedwards.ai/writing/what-the-cpr-summit-taught-me-about-ai-and-compliance/ I opened with a simple question: "How many of you have used an AI tool in the past week?" About 20% of the room raised their hands. This was the CPR Summit. Compliance, policy, and risk professionals from universities across Colorado. The people whose job it is to govern how institutions use technology. And only one in five had touched an AI tool in the past week. I don't say that to judge. It makes sense from a risk perspective. These are people trained to be cautious. But it also doesn't quite make sense, because of how much of their work is built on the written word. Policy drafting. Contract review. Risk assessments. Audit preparation. Compliance communications. Every one of those is a task AI can help with. Every one of them is currently done mostly by hand. ## The risk conversation is everywhere The room talked about lawsuits constantly. Third-party litigation financing. Social inflation. "Nuclear verdicts." That phrase came up more than once. The difference between proactive and reactive risk management was basically the theme of the day. One of the simplest examples I heard was from a speaker talking about physical risk: "proactively put cones around the cracked pavement before someone trips." It was about slip-and-fall liability, but the same logic applies to AI governance. Don't wait for the incident to happen. Not everything in that room is meant for AI. Insider threat analysis, threat assessment, and physical security are human judgment domains where a model adds less than it risks. But the gap between what AI can already do and what's actually being used is enormous. The people in that room are the ones who have to close it. ## The engaged ones were really engaged The people who were interested asked probing questions. About Claude licensing and whether enterprise agreements cover what they think they cover. About whether we could form a Colorado-wide AI knowledge sharing group across universities. About the difference between AI guidance and formal policy, which is a question I've been wrestling with myself. People took notes. Notes on how they could use AI in their own work starting Monday. They shared the same struggles we've had at CSU: choosing between guidance and policy as the right instrument for a given situation, integrating AI across research, teaching and learning, and administrative uses, and dealing with the reality that everyone is moving at different speeds. ## What I'm taking away The CPR Summit reminded me that the AI adoption problem is an organizational problem, not a technology one. The people who need to govern AI are the least likely to have used it, and the people who are using it are the least likely to know what governance looks like. Bridging that gap is most of the work. The audience taught me something I had not planned to learn. The most useful thing I can do for a compliance professional is show them what AI does for someone in their exact role, doing their exact kind of work. Policy drafting. Contract review. Risk assessment templates. Not how the model works. What it produces. That may end up leading them to understanding how and why governance is necessary. If your institution is working through the same questions about guidance versus policy, shadow AI, or federated governance, I would like to compare notes. Find me on the [about page](/about/). --- ## Why this site exists > A place to show the work, write down what building it taught me, and prove that 'AI Strategist' is a real job and not just a LinkedIn title. Published: 2026-07-05 · Canonical: https://davidedwards.ai/writing/why-this-site-exists/ For the past year-ish my job title has been **AI Strategist** at Colorado State University. That sounds like someone who sits in a glass office monitoring model releases, and hyping up AI. In practice, it means I'm the person campus calls when "we should do something with AI" needs to become a thing that exists: an API gateway researchers can actually use, an agent that answers accurately, or a governance answer that holds up when legal counsel reads it. Most of that work is invisible outside the rooms where it happens. This site is where I make it visible. ## What's here **Projects.** Working systems and the institutional work around them, described honestly, including what I'd do differently. Right now that's a [self-service AI API gateway](/projects/csu-ai-gateway/) for researchers, a [personal memory server](/projects/davids-brain/) that every AI assistant I use shares, the [method behind campus agents](/projects/campus-agents/) that hold up in production, and the [governance and adoption work](/projects/ai-strategy-governance/) that determines whether any of it matters. **Writing.** Notes from the build. Not AI hype, not doom. The practical middle: what worked, what didn't, and what I think it means if you're trying to do something similar. ## Who this is for Anyone interested in AI, hopefully. If you're new to this stuff, I'll tell you what things are before assuming you care about them; you should be able to read any page here without a glossary. If you're deep in it, the architecture and the hard won details are all there too, and headers exist so you can skip my explanations of what MCP is. ## Fair warning My GitHub handle is [doofusdavid](https://github.com/doofusdavid), which should set expectations about how seriously I take myself. The work, though, I take very seriously. Twenty years of shipping web systems taught me that technology adoption is mostly an organizational problem, and AI is no exception: the models are ahead of most institutions' ability to absorb them, and that gap is where the interesting work lives. I'd rather demo a prototype than present a maturity framework. But I've also learned that the prototype only matters if the governance, guidance, and adoption work happens around it, so this site covers both halves: the things I've built, and the institutional change that made them stick. If you're doing similar work, in higher ed or anywhere else, I'd like to compare notes. You can find me on the [about page](/about/). --- ## What the Microsoft Foundry Claude question actually taught us > Data governance at a university isn't one problem. It's legal risk, technical residency, and trust, all wearing the same trench coat. Published: 2026-07-02 · Canonical: https://davidedwards.ai/writing/what-the-microsoft-foundry-claude-question-actually-taught-us/ Some version of this question arrives every few weeks: "Can I use [AI tool] for [data]?" Sounds simple. It really, really isn't. Behind it are three separate problems in a trench coat: a legal risk question, a technical residency question, and a trust question. Most guidance documents answer one and call it done. Chasing all three down on a real example, whether Claude via Azure AI Foundry is safe for university data, is more illuminating than any single answer. ## The three questions people are actually asking When staff, faculty, or a data governance committee ask "is this AI tool safe," they're really asking: **Is this legal?** Colorado passed an AI law in 2026 that targets high-risk uses: employment, housing, financial services, health care. The EU AI Act goes further and treats profiling as high-risk on its own. Our legal counsel's read: start with what Colorado requires, then decide where to over-comply. Employment is the sharpest edge here. Workday is currently being sued over AI use in hiring, a live reminder that even a well-intentioned use (comparing employee self-evaluations for consistency, say) can land you in a high-risk category you didn't think you were in. **Where does the data actually go?** This is the one people assume is settled and usually isn't. "It's a Microsoft product" and "it runs on Microsoft infrastructure" are not the same claim, and vendors are inconsistent about which one they mean. **Can you trust what a privacy toggle tells you?** Incognito mode, private browsing, "don't train on my data" checkboxes: these create a feeling of safety that outruns what they actually guarantee. Our counsel's line, which I now say constantly: vendors can still retain flagged content for review, privacy settings or not. None of these questions are answerable by reading a vendor's marketing page. You have to go source by source. Which is what we did. ## The Foundry Claude example Anthropic's Claude models are available through Azure AI Foundry, which matters to us because our Claude usage flows through an API gateway sitting on our Microsoft enterprise agreement. The assumption inside that setup was reasonable: it's Microsoft infrastructure, covered by our Microsoft data processing agreement, done. That assumption was wrong. The reason is a case study in reading past a vendor's summary paragraph. **Anthropic is the data processor, not Microsoft.** Regardless of which hosting option you pick, Anthropic operates the model inference and is the independent processor of your prompts and completions under Anthropic's own commercial terms. Microsoft's enterprise agreement covers the infrastructure, identity, and billing layer around Foundry. It does not extend to what happens to your prompt once it reaches the model. This is a real difference from Azure OpenAI, where Microsoft is the processor end to end. **"Hosted on Azure" is new, and it's the fix.** Foundry Claude launched in preview running entirely on Anthropic's own hardware, which meant your data could leave your region regardless of what you configured. As of general availability on July 1, 2026, there are two hosting options: the new default, "Hosted on Azure" (ingress, API calls, and GPU inference all happen inside Azure, data at rest stays in your chosen Azure geography), and the legacy "Hosted on Anthropic infrastructure" (the old preview path, data may leave your region). Which option a given deployment uses is now the single most consequential setting in the whole configuration, and it's easy to get wrong if nobody goes back to check it after GA. **Even the vendors' own docs disagree with each other.** Microsoft's documentation says GPU inference for "Hosted on Azure" runs on Azure hardware. Anthropic's own third-party integration notes say Claude models run on Anthropic's infrastructure. Both are technically defensible depending on how you define "runs," but if you're trying to write a data governance policy, that kind of internal contradiction between two vendors describing the same product is a flag to escalate, not something to paper over with a footnote. **Zero data retention is not a checkbox.** You can request that Anthropic not retain your prompts after the call completes, but on Foundry this has to be arranged in writing between your Microsoft account team and Anthropic. It is not something you turn on in the portal. Treat every deployment as retaining data until you have that confirmation on paper. **Safety review still happens, even with retention off.** Anthropic runs automated classifiers on every request looking for policy violations. Flagged content can go to human review at Anthropic, and confirmed violations get retained for up to two years for abuse monitoring, independent of your retention settings. This is the part most people don't expect: "zero data retention" describes your prompt history, not the safety layer sitting on top of it. ## What we came up with We mapped this to the four data classification levels our university system already uses (public, internal, confidential, restricted) and landed here: - **Public and internal data:** fine on Foundry Claude today, hosted on Azure, no special approval needed. - **Confidential data** (personnel records, assessment data, most PII): conditionally fine, but only once zero data retention is confirmed in writing for that specific subscription, and only with data governance committee sign-off. - **Restricted data** (biometric data, controlled unclassified information, Social Security numbers, financial account numbers): not through Foundry Claude, full stop, unless someone produces a signed data protection arrangement that specifically covers it. We also flagged a narrower but nastier problem: a small set of Anthropic's models come with mandatory retention and no zero-retention option available, on any platform. If your organization has a standing zero-retention agreement, using one of those specific models silently requires you to turn retention back on for it. That's the kind of setting nobody notices until an audit finds it, so it's now something we check explicitly during any Claude deployment, not an assumption we make. None of this makes Foundry Claude unusable. It makes it usable with the right defaults and the right paperwork, which is a very different thing from "it's Microsoft, so it's covered." ## The pattern, not just the example The real point isn't Claude specifically; it's the method. Every AI tool question that shows up at a university has the same three layers underneath it, and skipping any one of them gets you a wrong answer that sounds confident: 1. What does the law actually require for this use case, not the general case. 2. Where does the data physically go, and who is the processor once it gets there, regardless of whose logo is on the product. 3. What do the privacy settings actually guarantee, versus what they imply. We're now building this into how we vet AI tools before they touch university data: a short checklist, a data steward as the approval gate instead of individual discretion, and default template language disclosing AI use wherever it applies. None of that is exciting. It's also the difference between a governance program that catches the Foundry Claude problem before it becomes an incident, and one that finds out from a vendor's fine print after the fact. If your institution is working through the same kind of question, I'd like to compare notes. Find me on the [about page](/about/).