> ## Content Index > Fetch the complete content index at: https://www.missionviewpoint.com/llms.txt > Use this file to discover other available public pages before exploring further. # You're Using AI. That's Not the Same as Building It. - URL: https://www.missionviewpoint.com/youre-using-ai-thats-not-the-same-as-building-it/ - Published: 2026-08-19T16:30:14.000Z - Updated: 2026-08-19T18:08:34.000Z - Author: Scott Dickson - Tags: Topic: AI & Automation, Topic: Care Organizations at Scale ***Part One of MissionViewpoint's series: AI doesn't create organizational intelligence. It amplifies it.*** Ask an ABA provider today whether they're using AI and the answer is increasingly likely to be yes. Their clinical platform may help **draft notes**. Their scheduling system may **optimize assignments**. Their revenue-cycle tools may **identify billing problems**. Their recruiting software may **screen candidates**. Their practice management platform may **surface operational insights**. And these capabilities are **genuinely useful**. But there's an **important distinction hiding inside** that answer. It isn't the one the question implies. The real distinction isn't between using AI and building it. **Most providers shouldn't build anything.** It's between having software that **uses AI** and **having organizational AI capability**. > **Those are not the same thing.** ## The Application Inherits a Boundary Every software application **has a field of view**. A scheduling system knows the **schedule**. An authorization tool knows **authorizations**. An Applicant Tracking System knows **candidates**. A CRM knows the **intake** pipeline. A Practice Management platform may know clinical delivery, billing, scheduling, and other parts of the operation. AI can make each of those applications **considerably more capable**. But the AI generally **inherits the application's view of the organization**. That isn't necessarily a weakness in the product. If you want to know which authorizations expire in the next 30 days, an authorization system may have everything it needs to **answer the question exceptionally well**. The limitation becomes apparent when the question changes. **Which authorization puts the most delivered care at risk?** Now an expiration date **isn't enough**. You might need to know how many hours **remain**, how **quickly** the client is using them, whether the case is **fully staffed**, what is **currently scheduled**, whether the BCBA has **sufficient capacity**, how long that payor typically takes to approve a renewal, and whether anything else is already **putting service delivery at risk**. The question began with an authorization. **The answer may live across the organization.** ## The Questions That Run an Organization Don't Respect Software Boundaries Consider a provider with two regions. One is delivering 91% of authorized care. The other is delivering 78%. Why? The Practice Management software can tell you **what was delivered**, and the scheduling system may show **open shifts and cancellations**. The HR and recruiting packages may show **vacancies, turnover,** and **candidates** in the pipeline. Authorization data may reveal clients whose approved hours changed or whose **renewals are delayed**, and payroll may show **overtime patterns** or **workforce availability**. **Each system can accurately describe its part of the operation**. But none of them necessarily knows **why** the region is at 78%. Maybe technicians are **leaving faster than recruiting can replace them**, or staffing looks adequate in aggregate but the available employees **don't line up geographically** with the clients who have open hours. Maybe authorizations are arriving late, or **cancellations are concentrated** in a handful of cases, or BCBA capacity is **quietly constraining** technician assignments. More likely several of those are **interacting at once -** which is precisely why no single system can answer it. That's an **organizational question**, not an application question. And making every individual application smarter doesn't necessarily make the organization smarter. ## Application Intelligence Is Not Organizational Intelligence This is where I think some of the conversation about AI in ABA is getting ahead of itself. We tend to measure AI adoption by counting capabilities. Does the platform generate notes? Optimize schedules? Review documentation? Predict authorization risk? Those are reasonable questions when evaluating a product. **They're less useful when evaluating an organization's capability.** A provider could steadily add increasingly sophisticated AI features to nearly every application it uses and **still have limited ability** to apply intelligence across the operation. That's because AI cannot reason across context it doesn't have. The important distinction isn't between vendor AI and provider-built AI. Providers **don't need to train foundation models**, **build their own LLMs**, or **become software companies**. The distinction is between **application intelligence** and **organizational AI capability**. Application intelligence makes a particular piece of software **better at the job it was designed to perform**. Organizational AI capability makes enough of the organization's information and operating context available **to reason about problems that don't fit neatly inside one application**. Those are different capabilities. ## AI Raises the Stakes of Technology Architecture This is an extension of an argument I've made before. ABA providers increasingly operate across a collection of systems of record. Practice Management, clinical data collection, CRM, recruiting, HR, payroll, finance, and specialized operational tools **each hold part of the organization's information**. I've argued that providers need an [operating layer above those applications](https://www.missionviewpoint.com/how-operating-layers-create-strategic-advantage-adaptability/) \- and a [data spine](https://www.missionviewpoint.com/why-every-provider-needs-a-data-spine/) capable of connecting the information required to make decisions across them. That was already an operational issue. **AI makes it an intelligence issue**. When information is fragmented, **people compensate**. They export reports, build spreadsheets, hold meetings, send messages, and ask the person who "knows how this works." Experienced operators **become the connective tissue** between systems. AI doesn't automatically remove that fragmentation. **In some ways, it exposes it**. If intelligence is increasingly embedded inside applications while the information required to operate the organization remains distributed across them, **we may end up with remarkably intelligent software surrounded by many of the same organizational blind spots**. The architecture starts to create an **intelligence ceiling**. What your organization can ask AI increasingly depends on what context you can make available to it. ## And Some of the Most Important Context Isn't in a System at All There's another complication. Even if a provider could connect every application tomorrow, **it still wouldn't capture everything the organization knows.** An experienced scheduler knows that two technicians who look interchangeable in the system **aren't actually interchangeable**. An authorization specialist knows that one payor's remaining units should trigger concern while another payor's apparently identical situation **is routine**. A regional leader knows that a staffing problem that looks manageable on a dashboard is about to become much harder because of **something happening locally**. Organizations accumulate thousands of these judgments. Some are documented. Many aren't. They live in **experience, habits, exceptions, conversations**, and **the heads of the people** who have learned how the organization actually works. That may turn out to be one of the more consequential opportunities AI creates. But first, providers need to distinguish between having access to AI and **building the organizational capability to use it**. ## What Can Your Organization Actually Know? "We're using AI" will soon tell us very little about an ABA provider's technology strategy. Nearly everyone will be using it. The more interesting question is what the organization has made available to intelligence. Can AI see only the schedule, or can it **understand why** scheduled care isn't being delivered? Can it see an authorization approaching expiration, or can it **understand what** that expiration means for staffing, utilization, revenue, and client access? Can it answer questions about a **system**, or questions about the **organization**? The providers that develop that capability won't necessarily be the ones with the most AI features. They'll be the ones that have made more of their organization **intelligible**. Because AI doesn't create organizational intelligence. **It amplifies what the organization can make available to it.** --- **Coming next: Point AI at Your Own Operations** In Part Two, I'll explore how AI may give providers a new way to capture that institutional knowledge - and turn more of what their people know into organizational capability.