What’s inside

1. Tokens & hallucinations: how much an AI can actually hold in its head, and why it makes things up when it runs short.

2. Web app, desktop, CLI & API: the four doors to the same AI, from easiest to most powerful.

3. Chatbots, Projects & Custom GPTs: the three modes you’ll meet inside, and when to climb from one to the next.

4. Tools that plug into AI: the fast-growing ecosystem, and the two ways outside apps connect.

5. Sub-agents: how AI teams up on jobs too big for a single sitting.

This guide covers five things every AI user should understand: how much an AI can actually hold in its head (tokens, and the hallucinations that happen when it runs short), the different doors you can reach it through (web app, desktop, CLI, API), the different modes you’ll meet once you’re inside (chatbots, Projects, and Custom GPTs), the fast-growing world of everyday tools that plug into AI, and a peek ahead at sub-agents, the way AI teams up on jobs too big for one sitting. The first explains why AI behaves the way it does; the rest explain how to work with it.

Part 1: What Are Tokens?

Think of tokens as how much text an AI can hold in its head at once.

A token is roughly ¾ of a word, so a single page of text (about 500 words) works out to around 700 tokens.

Now imagine the AI has a strict limit on how many pages it can hold in its head at any one time. It reads them instantly and understands them perfectly, but its entire working memory is capped at that stack of pages. A typical limit today is 200,000 tokens, roughly 285 pages, about the length of a paperback novel.

Every question you ask, every answer it gives, and every document you attach has to fit inside that stack. (The technical name for this stack is the context window; whenever you hear that term, just picture the stack of pages.)

And note that word: attach. Files count too. The moment you upload a document, its entire contents land on the stack, page for page, exactly as if you had typed it all in yourself. Attach a 50-page sponsor agreement and you’ve used roughly 35,000 tokens before you’ve even asked your first question.

The Part Most People Miss

When you chat with an AI, it doesn’t actually remember you between messages. Each time you hit send, it re-reads the entire conversation from the beginning to work out what to say next.

Stick with the email analogy:

• You send a 5-line email. The AI replies with 5 lines.

• You reply again, but now the “email” contains your first 5 lines + its 5-line reply + your new message.

• Every new turn carries the full weight of everything said before it.

So the stack fills up fast. And if you’re attaching files or documents, they eat into that same page count far quicker than most people expect.

Video i made a few years ago to show how this works

Why AI Used to “Forget”

In the early days, the stack was small, often just a few pages. Once the conversation outgrew it, the oldest pages simply fell off the bottom, so the AI genuinely couldn’t “see” how the chat started. That’s why it seemed to forget where you began.

Today the stacks are enormous. Some models handle 1,000,000 tokens, roughly 1,400 pages, yet you’d be surprised how quickly even that fills up with long chats and big attachments.

Modern systems like ChatGPT and Claude are also cleverer about it: rather than letting old material fall off the edge, they summarize and compact earlier parts of the conversation so the core points survive even after the raw text is gone.

And for really big jobs, there’s a more advanced trick still: rather than cram everything onto one stack, the work can be split across a team of AIs that each keep their own separate stack. We’ll come back to that at the very end, in Part 5.

What Is a “Hallucination”?

A hallucination is when an AI states something false but confident-sounding: inventing a fact, a quote, a statistic, or even a web link that never existed. The tricky part is that it sounds exactly as fluent and self-assured as when it’s right, so there’s no obvious “tell.”

Why It Happens

An AI doesn’t look things up the way you’d search a filing cabinet. Underneath, it’s a very sophisticated prediction engine: given everything on its stack of pages so far, it works out the most plausible next words. Usually the most plausible answer is also the correct one, but not always. When it doesn’t actually know something, it doesn’t stop and say “I’m not sure.” It simply predicts what a convincing answer would look like and hands that to you.

Think of a student in an exam who can’t remember a date. Rather than leave the answer blank, they write down something that feels about right. That’s a hallucination: a confident guess dressed up as a fact.

The Link to Tokens

This is where it connects back to the stack of pages. When the relevant information has fallen off the stack (because the conversation grew too long, or you never gave the AI the fact in the first place), it has a gap to fill. And filling gaps with plausible-sounding guesses is exactly what it’s built to do.

So while forgetting and hallucinating aren’t the same thing, they often go hand in hand:

• Forgetting / losing context: earlier text has fallen off the stack, so the AI no longer has it to refer to.

• Hallucination: the AI fills a gap in its knowledge with something invented but believable.

Forgetting is about memory running out; hallucination is about accuracy. One frequently triggers the other.

How to Reduce It

You can’t switch hallucinations off entirely, but you can make them far less likely:

• Give it the facts. Paste the document, figures, or context directly into the chat rather than trusting the AI to remember them. If it’s on the page, it doesn’t have to guess.

• Ask for sources. “Where did that come from?” often exposes an invented reference: real ones hold up, fake ones don’t.

• Verify anything that matters. Treat names, dates, numbers, quotes, and links as drafts to check, not gospel, especially for anything high-stakes.

• Keep chats focused. A shorter, on-topic conversation is less likely to push key facts off the bottom of the stack.

In short: the “stack of pages” is your token limit (each page ≈ 700 tokens). Everything (your messages, the AI’s replies, and your attachments) has to share it. Run out of room and the AI loses track of the start of the conversation; when it fills that gap with confident, invented detail, that’s a hallucination.

Part 2: Web App, Desktop, CLI & API

The same AI can be reached through several different doors. It’s the same brain behind each one. What changes is who the door is built for, and how much control it hands you.

A useful way to picture it: the four doors sit on a slider from “easiest to use” to “most powerful.” As you move along it, you trade simplicity for control.

Easiest ────► Web App → Desktop App → CLI → API ◄──── Most powerful

The first two are built for people. The last two are built for builders and power users.

Web App

The web app is the AI opened in your browser. You just visit a website and start typing. Nothing to install, works on any device, always the latest version.

🌐 Analogy: online banking through your browser. You go to the website, log in, and everything’s there. Convenient and zero setup, but you can only do what the website lets you do.

Best for: almost everyone, most of the time. It’s the default starting point.

Trade-off: it lives in a browser tab, so it can’t easily reach the files on your computer or work while you’re offline.

Desktop App

The desktop app is the same AI installed as a program on your computer. Because it’s on your machine, it can plug into things a browser tab can’t: reading local files, sitting in your menu bar, popping up with a keyboard shortcut, sometimes even seeing your screen.

💻 Analogy: the banking app on your phone versus the website. Same bank, but the app is better woven into your device: notifications, fingerprint login, quicker access.

Best for: people who use AI often and want it closer to their everyday work and files.

Trade-off: you have to install and update it, and it’s tied to that particular computer.

CLI (Command Line Interface)

The CLI is the AI driven by typed commands in a terminal, that black text window you’ve seen programmers use. No buttons, no chat bubbles; you type an instruction and it runs. In return you get real power and automation: it can work through hundreds of files, repeat a task automatically, and act directly on your computer.

Once the CLI is installed, it also becomes a hub you can connect other tools to. You can plug it into things like your files, your email, your calendar, a database, or your grants management system, and the AI can then read from and act on them directly, all from the one place. This is what turns it from a clever chat window into something that can genuinely do work for you across the tools you already use.

⌨️ Analogy: the cockpit controls instead of the passenger seat. Less comfortable, nothing is decorative, but you can fly the plane yourself and do things no passenger can.

Best for: developers and technical power users who want speed, automation, and hands-on control.

Trade-off: there’s a learning curve, and mistakes carry more weight because it can act on your system directly.

API (Application Programming Interface)

The API isn’t something you chat with at all. It’s how other software talks to the AI. There’s no window and no chat box; it’s a connection point that a program plugs into so the AI’s abilities can be built into another product. When an app you use has a “summarise this” or “ask AI” button, an API is usually working quietly behind it.

🔌 Analogy: the power socket in the wall. You don’t “use” the socket for its own sake; you plug appliances into it. The API is the socket that lets developers power their apps with AI.

Best for: businesses and developers building AI into their own products, websites, or workflows.

Trade-off: it only makes sense with code. On its own it does nothing you can see: it’s raw plumbing, not a finished tool.

Compare and Contrast

Web AppDesktop AppCLIAPIWho it’s forEveryoneFrequent usersTechnical power usersDevelopers / businessesSetupNone, just a websiteInstall a programInstall + learn commandsRequires writing codeReaches your files?NoYesYesOnly what a program feeds itAutomation / powerLowMediumHighHigh (built into software)Has a chat window?YesYesText-onlyNoAnalogyBanking websiteBanking appCockpit controlsPower socket in the wall

The one-line summary:

• Web App: open a browser and go.

• Desktop App: the same AI, woven into your computer.

• CLI: type commands for power and automation.

• API: the socket other software plugs into.

It’s the same AI behind every door. Most people happily live in the web app; the desktop app brings it closer to your daily work; the CLI and API are where builders and power users go when they need automation or want AI baked into something bigger.

Part 3: Chatbots, Projects & Custom GPTs

Once you’re inside a web app or desktop app, you’ll notice the same tool offers a few different modes: a plain chat, a Project, a Custom GPT. They look similar but do quite different jobs. Think of them as three rungs on a ladder: each one keeps more of your context ready to hand, and each takes more setup to get there.

Everything you learned about tokens in Part 1 explains why these modes exist: they’re really just different ways of managing that stack of pages.

What Is a Chatbot?

A chatbot is the basic AI conversation, the blank chat window you type into. You ask, it answers, you follow up. Simple.

The catch: each conversation starts from scratch. Open a new chat and the AI has no idea what you discussed yesterday. In the stack-of-pages analogy, every new chat is a fresh, empty stack.

🗣️ Analogy: talking to a brilliant stranger at a party. They know an enormous amount and give great answers, but the moment you walk away, they forget you entirely. Come back tomorrow and you’re introducing yourself all over again.

Best for: quick questions, one-off tasks, brainstorming, anything you don’t need to revisit.

What Is a Project?

A Project is a workspace that groups related chats together and holds shared material (files, notes, and standing instructions) that every chat inside it can see.

The key difference from a plain chatbot: that shared material persists. Upload your sponsor’s proposal guidelines and your institution’s style guide once, and every chat in the Project automatically has them on the stack. You’re not re-explaining yourself each time.

🗂️ Analogy: a dedicated meeting room with your reference documents laid out on the table. Anyone who walks in can see them without you fetching them again. Each conversation is still separate, but they all share the same room and the same materials.

Best for: ongoing work with a consistent backdrop, such as a grant proposal you’re preparing, a specific award you’re managing, a department’s research portfolio, or a recurring sponsor relationship. Anything where you’d otherwise keep pasting the same context into every chat.

What Is a Custom GPT (or Custom Assistant)?

A Custom GPT is a pre-configured assistant. You set it up once (its personality, its rules, its reference knowledge) and from then on it behaves that way every single time, without you repeating the setup. Crucially, you can often share it so other people can use it too.

Where a Project shares context across your chats, a Custom GPT bakes the instructions in and turns the whole thing into a reusable, shareable tool.

🤖 Analogy: instead of briefing a temp every morning, you train a specialist once (”you’re our friendly pre-award grants helpdesk, here’s our sponsor and institutional policy, always reply in plain English”) and then anyone in the office can go ask them. The training sticks, and it’s the same for everyone.

Best for: a repeatable job done the same way over and over, especially one you want to hand to others: a proposal-budget helper, an “explain this sponsor’s terms in plain English” assistant, or a checker that keeps every submission consistent and compliant.

Compare and Contrast

ChatbotProjectCustom GPTWhat it isA single conversationA workspace grouping related chatsA pre-built, reusable assistantRemembers context?No, each chat is blankYes, shared across its chatsYes, baked in permanentlySetup effortNoneA little (add files/instructions)More (define its behaviour)Reusable?NoWithin the workspaceYes, every timeShareable with others?NoSometimesYes, that’s the pointAnalogyA stranger at a partyA meeting room with your filesA trained specialistBest forQuick, one-off questionsOngoing work with steady contextRepeatable tasks, especially shared

The one-line summary:

• Chatbot: ask a question.

• Project: keep your context in one place.

• Custom GPT: build a helper once, reuse (and share) it forever.

They’re not rivals; they’re steps up a ladder. Start in a chatbot. When you’re tired of re-pasting the same background, graduate to a Project. When you (or your team) want to do the same job the same way again and again, build a Custom GPT.

Part 4: The Wider World of Tools That Plug Into AI

Here’s where it gets interesting. AI companies like OpenAI and Anthropic (the maker of Claude) don’t just sell you a chat window; they let other products borrow their AI. The result is a huge and fast-growing ecosystem: a near-endless list of apps, tools, and services that quietly run on Claude or ChatGPT behind the scenes. Your note-taking app, your email, your grants management system, your reporting tools, all of them can have AI woven in without ever building their own.

There are two main ways these outside tools connect, and the difference really matters.

Connecting Through an API Key

The most common route is an API key. Think of it as a password-like code you copy from your AI account and paste into another product. From then on, that product can use the AI’s brainpower on your behalf, billed by how much you use, usually separately from your chat subscription.

🔑 Analogy: giving a trusted contractor a key to one specific room. They can come in and use what’s in that room, but only that room. The AI answers the tool’s requests, but it doesn’t automatically know anything about you beyond what the tool chooses to send it.

This is simple, flexible, and everywhere. The limitation is that each tool starts from a blank slate: it only knows what it passes to the AI in the moment.

“Hooking” Into Your Local AI Install

The more powerful route is when a tool hooks directly into the AI you’ve already installed on your machine (usually the desktop app or the CLI from Part 2). Instead of just borrowing raw brainpower through a key, it plugs into your whole setup.

That means it can leverage not only your subscription or API, but also everything your local AI already knows about how you work:

• your custom instructions (how you like it to respond),

• your custom skills (special abilities you’ve added),

• your connected tools (files, email, calendar, and the rest),

• and its memory of your projects and preferences.

🏠 Analogy: instead of a contractor with a key to one room, this is like giving a trusted assistant the run of your whole office. They already know where everything is, how you like things done, and who to call. They’re far more useful because they share your context, not just your electricity.

The trade-off is trust. A tool hooked this deeply into your setup can see and do a great deal, so it’s worth installing only ones you trust, and understanding what you’re granting access to.

The Takeaway

API keyLocal hookWhat the tool borrowsBrainpower onlyBrainpower plus your whole setupKnows your context?Only what it sends alongInstructions, skills, tools, memoryTrust requiredLowerHigherAnalogyKey to one roomRun of the office

• API key: lends a tool the AI’s brainpower. Simple, common, starts from scratch each time.

• Local hook: lends a tool the AI’s brainpower plus your whole personalised setup. More powerful, but asks for more trust.

Either way, the point is the same: AI is no longer just a website you visit. It’s becoming an engine that quietly powers a huge and growing range of the other tools you already use every day.

Part 5: A Peek Ahead at Sub-Agents

Back in Part 1, we met the one hard limit every AI lives with: its stack of pages. No matter how big that stack gets, a genuinely large job (reading a hundred documents, or assembling a huge report) can still overflow it. Sub-agents are one of the cleverest ways around this, and they’re where many of the most powerful AI tools are heading.

The Idea

Instead of one AI trying to hold an entire enormous task in its head at once, a lead AI called an orchestrator breaks the job into small, bite-sized chunks and hands each chunk to a separate helper AI, a sub-agent.

The clever part is what each sub-agent is given. Rather than handing every helper the whole pile of context, the orchestrator gives each one only the context it needs for its specific piece. That keeps each sub-agent’s stack of pages mostly empty, so it has plenty of room to actually think and work.

Black Boxes That Share Notes

You can picture each sub-agent as a black box: it takes in its small brief, works away independently, and hands back a result, without needing to know what any of the others are doing.

So how do they work together? Through a shared set of files. When a sub-agent finishes, it writes its result (or a question for another agent) into a shared location that the others, and the orchestrator, can read. It’s the AI equivalent of a team dropping finished documents into a shared folder for everyone else to pick up.

🧩 Analogy: think of a lead coordinator running a big grant submission. Rather than making one person write the entire proposal, they split it up: one specialist drafts the budget, another the project narrative, another checks compliance, another prepares the biosketches. Each only needs the brief for their own part, not the whole package. As each finishes, they drop their section into a shared folder, and the coordinator assembles the final submission. Nobody had to hold the entire thing in their head at once.

Why It Matters

This is how AI tackles jobs far too big for any single stack of pages. By dividing the work, giving each agent just enough context, and letting them exchange results through shared files, one huge and complex task becomes a set of small, manageable ones, each handled cleanly without drowning in context.

It’s the same principle any good manager uses: you don’t brief every team member on every detail of the whole project. You give each person what they need to do their part well, then coordinate the results.

Wrapping Up

If you remember one idea from each part, make it these:

1. Tokens: an AI’s memory is a stack of pages (its context window). Everything in your conversation has to fit on it.

2. Hallucinations: when the AI is missing a fact, it fills the gap with a confident guess. Give it the facts and verify what matters.

3. Access: web app, desktop app, CLI, and API are four doors to the same brain, running from easiest to most powerful.

4. Modes: chatbots, Projects, and Custom GPTs are a ladder. Climb a rung whenever you’re tired of repeating yourself.

5. Ecosystem and agents: AI increasingly powers the tools you already use, and big jobs get split across teams of sub-agents.

The best way to learn is simply to start: open the web app, ask real questions from your own work, and climb the ladder as the repetition starts to bug you. Everything else in this guide will make more sense once you’re using it daily.

Quick Glossary

• Token: the unit AI text is measured in; roughly ¾ of a word. About 700 tokens fit on one page.

• Context window: the AI’s working memory, the “stack of pages” everything must fit inside.

• Hallucination: a confident-sounding but false statement an AI produces when it fills a knowledge gap with a plausible guess.

• CLI (Command Line Interface): driving the AI by typed commands in a terminal, trading comfort for power and automation.

• API (Application Programming Interface): the connection point other software uses to plug into an AI.

• API key: the password-like code that lets another product borrow an AI’s brainpower on your account.

• Orchestrator: the lead AI that breaks a big job into chunks and hands them out.

• Sub-agent: a helper AI given one small chunk of a job and only the context it needs.

An AI’s memory is a limited “stack of pages” called the context window; everything in your chat has to fit on it, and when facts fall off (or were never there), the AI fills the gap with confident guesses called hallucinations. You can reach the same AI through four doors (web app, desktop app, CLI, API) that trade ease for power, and work with it in three modes (chatbot, Project, Custom GPT) that trade setup for memory. A growing ecosystem of everyday tools plugs into AI via API keys or by hooking into your local install, and the biggest jobs get split across teams of sub-agents so no single AI has to hold everything at once.

If you work in AI you know the tax.

Your tools speak Markdown.

Your institution speaks Word and Google Docs.

Every paste between them turns clean output into a mess of hashes and asterisks, and you fix it by hand.

Markdown is the universal format.

Writage is the bridge.

It is a Word plugin. Paste from Claude, ChatGPT, or Gemini and it renders properly via paste as markdown: headings, lists, tables, code, math.

Copy any Word selection straight back out as Markdown, or save the whole file as a clean Markdown document for Obsidian or GitHub. Clipboard or file, both directions.

Essential if you want to become an AI native.

Thirty-five dollars, one time, no subscription. Fourteen day free trial. I use it constantly. Best thirty-five bucks you will spend this year.

I pay for the product, but discovered after your 14 day trial ends you still have the option to save/read Markdown files in MS Word, you just can’t copy/paste text blocks

TL;DR: AI isn’t getting smarter in the way most people think. The real shift is workflow. If you’re still using AI like a chatbot, you’re three years behind.
Every conversation starts from zero because the model has no persistent memory of you, your work, or your context. Claude Skills solve this by letting you build a reusable knowledge library, one markdown file per task, that the AI can pull from on demand.

Read full post here

TL;DR: AI isn’t getting smarter in the way most people think. The real shift is workflow. If you’re still using AI like a chatbot, you’re three years behind.
Every conversation starts from zero because the model has no persistent memory of you, your work, or your context. Claude Skills solve this by letting you build a reusable knowledge library, one markdown file per task, that the AI can pull from on demand.

Don’t want to read the blog, watch the video instead!

Click here to listen to podcast

I was busy the last few weeks getting ready for a conference and couldn’t dedicate my normal time to keeping up with AI. It had been a good four weeks since I’d been able to really go deep, and in just those four weeks the bleeding edge of workflows had changed.

If you’re in the early stages of learning AI, the capabilities feel relatively stable. You’re probably using chatbots, and if you’re adventurous, you’ve made a custom project or maybe a custom GPT. That’s a great start. It was also possible three years ago.

When you operate on the bleeding edge, there are major changes with almost every release. I’m not talking about AI intelligence or token limits. I’m talking about workflow. Think command line interfaces (CLI), more specifically Claude Code, and AI built directly into VS Code.

If you’re still using AI like a chatbot, congrats, you’re ahead of most people who aren’t using AI at all. But you’re about three years behind what’s now possible.

You need to start thinking of AI as a coworker you can offload real tasks to. I’ll write a separate post on Claude Code integration, but for now here’s the best way to explain where things are heading.

Context windows: the working memory problem

AI has what’s called a context window. Think of this as working memory (not really, but it’ll do for now). Every time you upload a file, ask a question, or get a response, it all has to be held in “memory.” Every time you talk to AI, it isn’t actually remembering your prior chats. What it’s doing is resending everything back and forth

I made this video a while back that explains this better:

Even with one million token context windows, if you upload a few large PDFs, a video or two, and some data, you’ll burn through that in thirty minutes of chat.

If you’ve seen the TV series Severance, AI is essentially a severed worker. The intelligence is fully intact in both contexts. The innie version is just as smart as the outie. But the innie has no access to anything the outie knows. Every task they need to perform on the severed floor has to be taught to them.

Every AI conversation starts the same way. The model walks onto the severed floor having never met you. Anything you’ve worked on together before, any preferences, any context about your job, has to be reintroduced unless you give it a way to access that knowledge on its own.

While not strictly true any more with custom instructions and a kind of persisting memory which auto updates, for this post lets assume that is not he case as it is very basic at best.

That’s the problem skills solve.

Build a Knowledge Library

New mindset: Google “Claude Skills” for the in-depth understanding.

Claude is the best AI at this right now, but the concept is coming to all AI eventually.

Take your last five years worth of projects, both in and out of work. Now imagine you had to train someone else to fully understand and perform these tasks. All they had to go from was your written instructions, knowledge, computer code, notes, and references. Everything would need to be in a machine accessible format.

That’s a lot of knowledge to upload every time you talk to AI.

The Library of You

This is the best metaphor I’ve used for explaining skills.

Imagine a library.

Each book is a part of your life at the task level.

Each book has an executive summary.

Each page contains what’s needed to complete the task: background knowledge, computer code, API information, instructions on how to learn more from other books in your library, lessons learned, things to watch out for, reference material, and so on.

Take the last project or task you completed at work or at home. If you had to document it step by step, including all the information listed above, it gets pretty big. Even for basic tasks, you have to provide all the relevant context.

A Concrete Example

Say you want to give a presentation at a conference on “Repurposing Sponsored Research Data for Collaboration Network Analytics.” Let’s just focus on the opening slides. You’ll probably need an introduction covering who you are, what you do, and why you’re qualified to speak on this topic.

Slide: Who am I?

• What you’re speaking about

• What you’ve done on this topic

• Relevant professional history

• Educational background

• What project from your job makes you qualified to speak on this

• What tools you use, what other projects are related

• Past talks and webinars

Sure, you could type this out every time you build a new presentation. But things get out of sync, and that’s a lot of duplication of effort. What if you want to write a blog post on it, change the audience, or repurpose the talk for an adjacent area?

Use Your Library

Let’s pull three books off the shelf: “Resume,” “Project Details,” and “Past Presentations.”

Behind the scenes, when you ask “make me an introduction for that talk,” the AI will:

1. Read the slide deck to understand the context

2. Read any guidance around the audience (level, familiarity with the topic, etc.)

3. Read your past presentations

4. Use all of this to draft an appropriate introduction

Even this simple act of generating an introduction isn’t actually simple. Humans take knowledge for granted. We can recall all of this stuff without much thought. But if you have to upload or type it out every time (which is essentially what you’re doing if you’re still thinking in terms of chatbots, projects, or custom GPTs), it adds up fast.

Now imagine you have to repurpose your slides for a different audience or level. Maybe a year from now you’ve improved the tools you use for this project. Or maybe you want to write a blog post, a how-to for your colleagues, or a nice infographic.

That’s more manual effort you have to expend every single time, unless you build the library once and reuse it.

The Shift in Mindset

The move from chatbot to coworker isn’t about a smarter model.

It’s about giving the model access to you: your work, your context, your accumulated judgment.

The intelligence has been there for a while. What’s new is the infrastructure to make your knowledge portable.

This isn’t free. You actually have to write the books. The first few skills feel like overhead. The payoff shows up the third or fourth time you reach for one and realize you didn’t have to re-explain anything.

If you take one thing from this post, it’s that the bottleneck is no longer the AI.

It’s how much of yourself you’ve made machine-readable.

More context AI Feels Useless Because It Can’t See Your Work (Short Version)
More context Building a Task System with Structured Markdown Files

How to start

Don’t try to retroactively document the last five years of your work. That’s a recipe for never starting.

Start now, with the next project or action item on your plate. Open a blank markdown file. Write the how-to as you do the work. Then do the same thing for the next task. And the next. Twelve weeks in, you’ll be surprised how large your knowledge base has gotten.

The foundation unit is the .md file. As I covered in a prior post, I’m actively moving toward a “Files Over Apps” framework, where the foundation of all your work is a raw text file rather than something locked inside a proprietary tool. Plain markdown is the lowest friction format for AI to read and write. No export step, no API, no vendor lock-in. The file is the file.

This is also why Obsidian matters.

https://obsidian.md/

Obsidian sits on top of a folder of plain markdown files and turns them into a navigable, linked knowledge base. Backlinks, graph views, plugins, presentation modes, all working on the same raw files. The files stay portable, in a format any tool (including AI) can read. But on top of that raw layer, Obsidian gives you an interface humans actually want to use. That dual nature is why I think Obsidian becomes the foundation tool for most knowledge workers in the next few years. The files work for AI. The interface works for you.

Obsidian is powerful enough that it needs its own multi-part series, which I’ll get to in a later post.

For now, just know that the .md files you start writing today will plug into it without any conversion work later.
Obsidian is free, and has a very steep learning curve so start now
https://obsidian.md/

My additional notes using Obsidian
Markdown + Kanban - by Robert Pilgrim

Today, start a running Word file (convert it to text/md later) and see what you end up with in a few weeks! details project, task, relevant discussion points etc. 4 weeks from now just give it to AI and you will be surprised how powerful that file is!

Listen to a 90 Second overview below or click here for 30 minute deep-dive

Overview

A well-structured file system establishes the substrate: durable, portable, AI-readable data. But a well-structured file handed to an AI cold still produces generic output. The model lacks the interpretive layer required to reason about your work in context.

That gap has a structure. Think of it as a stack. Each layer is a prerequisite for the one next to it. Skipping layers does not accelerate output, it degrades quality in ways that are easy to misdiagnose as model limitations.

The Layers

Layer 1: Purpose
Define what this workspace is for. Strategic planning, faculty development, research development, compliance, institutional reporting: each carries different reasoning requirements. Without an explicit purpose definition, the model defaults to generic reasoning. This is the load-bearing layer everything else depends on.

Layer 2: Organizational Identity
Who is asking, in what role, within what institutional structure? This encodes your unit’s mandate, reporting relationships, and key stakeholders, whether that is a VPR, provost, faculty governance body, or federal sponsor. It allows the model to interpret the same question differently depending on where it is being asked from.

Layer 3: Strategy
What direction is your unit moving? Current priorities, multi-year initiatives, known constraints and competing pressures. Without this layer, the model evaluates options against generalized best practices rather than your actual criteria. This is what separates strategic reasoning from informed noise.

Layer 4: Current Data
Live institutional information: active initiatives, workforce data, benchmarks, draft documents, survey results, budget snapshots. This is where FILE pays off directly because your data is already in a format the model can parse. At this layer, AI shifts from general advisor to analytical partner operating on your actual situation.

Layer 5: The Query
Only here does prompt quality become the primary performance variable. A precise query on a fully loaded stack produces fundamentally different output than the same query on an empty context. Most users are optimizing this layer while the four beneath it remain unbuilt.

What This Looks Like in Practice

Note: The following examples are AI-generated illustrations.
The structure is identical across every role and function. The foundation layer, identity, strategy, data, and work are constant. Only the content inside each file changes. Three examples illustrate the point.

A HERD Survey Analyst

The decisions.md file carries particular value here. HERD is full of judgment calls: how you classify interdisciplinary expenditures, how you handle cost sharing, how you aggregate agency codes. Logging those decisions means next year’s submission starts with institutional memory already loaded rather than rebuilt from scratch.

/division-research-innovation/
│
├── PROJECT.md                            ← Purpose: HERD survey
│                                       preparation and submission
├── /about/
│   ├── about-business.md            ← DRI mandate, NSF relationship,
│   │                                   survey obligations
│   └── about-you.md                 ← Your role, data access,
│                                       key contacts
├── /strategy/
│   └── strategy.md                  ← NACUBO mapping, F&A methodology,
│                                       prior year decisions
├── /data/
│   └── current-data.md              ← Expenditures by source, discipline
│                                       codes, peer benchmarks
└── /work/
    ├── /herd-2026/
    │   ├── project.md               ← Scope, timeline, contacts
    │   ├── tasks.md                 ← Open items, deadlines
    │   ├── decisions.md             ← Classification calls, edge cases,
    │   │                               methodology changes
    │   └── log.md                   ← Anomalies, coordinator updates
    └── herd-status.md               ← AI-generated readiness brief

A VP of Faculty Affairs

/faculty-affairs-vp/
│
├── PROJECT.md                    ← Purpose, orientation
├── /identity/
│   ├── office-overview.md           ← Mandate, scope, authority
│   ├── stakeholders.md              ← Provost, deans, faculty senate
│   └── governance.md                ← Policy ownership, committees
├── /strategy/
│   ├── priorities-2026.md           ← Retention, equity goals
│   ├── initiatives.md               ← DEI programs, policy reform
│   └── constraints.md               ← Budget limits, union agreements
├── /data/
│   ├── faculty-demographics.md
│   ├── promotion-pipeline.md
│   ├── retention-risk.md
│   └── compensation-benchmarks.md
└── /work/
    ├── /policy-review-2026/
    ├── /faculty-leadership-program/
    ├── /promotion-cycle-2026/
    └── weekly-briefing.md

A Director of a Newly Formed Industry Partnership Hub

A newly formed hub will make a lot of foundational calls early: what sectors to prioritize, how to structure tiered partnerships, what a university brings versus what an industry partner expects. Logging those decisions in decisions.md means institutional memory survives staff turnover and the reasoning behind early choices stays accessible as the hub scales.

/innovation-hub/
│
├── PROJECT.md                            ← Purpose: establish and operate
│                                       a new collaboration and industry
│                                       partnership hub
├── /about/
│   ├── about-business.md            ← Hub mandate, university backing,
│   │                                   founding charter, success metrics
│   └── about-you.md                 ← Your role, decision authority,
│                                       key relationships
├── /strategy/
│   └── strategy.md                  ← Partnership model, target sectors,
│                                       engagement pipeline, revenue goals
├── /data/
│   └── current-data.md              ← Active partner conversations,
│                                       MOU status, space utilization,
│                                       pipeline metrics, peer benchmarks
└── /work/
    ├── /partner-pipeline/
    │   ├── project.md
    │   ├── tasks.md
    │   ├── decisions.md             ← Partnership terms, exclusivity
    │   │                               calls, tier structure decisions
    │   └── log.md
    ├── /hub-launch/
    │   └── project.md
    ├── /programming/
    │   └── project.md
    └── weekly-briefing.md           ← AI-generated pipeline summary

File Reference

These are the core files you need for each project, preferably as Markdown (.md) files.

• PROJECT.md -Purpose and orientation of the workspace. Tells the AI what this context is for before anything else is loaded.

• about-business.md - The institutional or organizational context. Mandate, structure, reporting lines, key obligations.

• about-you.md - Your personal context. Role, decision authority, working style, key relationships.

• strategy.md -Current direction. Active priorities, multi-year goals, known constraints, approach and methodology.

• current-data.md - Live snapshot of where things stand right now. Metrics, benchmarks, active portfolio, current state.

• project.md - Scope and goals for a specific project. What it is, why it exists, who is involved.

• tasks.md -Current task list. Open items, owners, deadlines, status.

• decisions.md - Log of key decisions made. What was decided, why, and by whom. Institutional memory.

• log.md - Running narrative of progress. Updates, blockers, anomalies, meeting notes.

• weekly-briefing.md - AI-generated summary pulled from the work folder. Status, risks, priorities, next steps.

The Operational Implication

The Context Stack is not a one-time setup. It is a design principle for how you can move to an AI-First workflow. Central to that workflow is the concept of a context artifact: any pre-built, reusable document that AI can load and reason from.

Drop these files in you AI chatbot of choice to start using this workflow

Orientation documents, strategic briefs, and current-state snapshots are all context artifacts. Build them once, and they eliminate the need to re-explain your situation at the start of every session. Loading them collapses the distance between institutional knowledge and AI output.

The Context Stack tells AI what to do with it.

The units that extract durable value from AI will not be those with the best prompts. They will be the ones that treat institutional context as infrastructure.

In the previous post, i argued that an AI-First workflow requires operational work to live in open Markdown files.

Here’s a concrete example video

On the left of the video: Raw Markdown task list.
On the right of the video: Kanban board generated from that same file using an Obsidian plugin. Obsidian is a free Markdown based program.

There is no separate database. No synchronization. No export step.

The board is just a visual layer. The Markdown file is the system of record.

NO FRICTION for AI

Why This Matters

Because the tasks live in plain text:

• AI can read and write directly to the source.

• It can scan every project folder in seconds.

• It can aggregate active tasks across projects.

• It can generate weekly summaries automatically.

• It can build cross-team views on demand.

  Work within the limitations of your authorized AI tech stack by changing to an AI-First workflow. All data is stored locally.

  

No APIs.
No vendor lock-in.
No integration friction.

AI doesn’t need access to your app.

It needs access to your files.

Next Steps

Get Obsidian for free here (or VS Code if you already have it)

Install the Kanban Plugin

Designing Task Files That Support Automation and AI Collaboration

TL;DR: Most task tools store your work inside proprietary databases. Markdown stores tasks as structured text files you control. Using simple checkbox syntax and headings, a single Markdown file can function as a Kanban board, render into multiple views, and remain portable across tools.
When tasks exist as structured files, AI can read, summarize, and update them directly without fragile integrations or export loops.

Overview

Most task management software locks your work inside proprietary databases.

You do not own the structure. You only interact with it.

Markdown offers a different approach. Tasks become structured text files that you control, version, move, and render into interfaces when needed.

Files first. Interfaces second.

This is not a productivity tweak. It is an architectural decision.

This post covers:

1. How tasks are represented in Markdown

2. How that structure maps to Kanban workflows

3. Why structured text becomes strategically important when layered with AI

This illustration shows an AI maturity model and the shift from standalone chat tools to systems operating directly on structured files, learn more here https://researchanalytics.substack.com/p/ai-feels-useless-because-it-cant

Tasks as a Text-Based Data Structure

A Markdown task is a predictable structural pattern.

Checkbox Syntax

- [ ] Open task
- [x] Completed task

Brackets define state.
Text defines the payload.

Subtasks are created through indentation:

- [ ] Parent task
    - [ ] Child task

Example:

This provides a minimal state model:

• Boolean completion

• Hierarchical nesting

• Ordered grouping

No database required.

Using Headings as Workflow States

Markdown headings introduce hierarchy.

# Project Name
## Pending
## Doing
## Done

Example:

Headings act as containers. In practice, this functions as a lightweight Kanban model:

• Each heading represents a column

• Tasks inherit the state of the heading above them

• Moving a task between headings changes its status

The structure is both human-readable and machine-parseable.

Rendering: Interface as a Layer

When opened in a Markdown-aware tool, the file can render as a visual board.
Example using Obsidian with a Kanban plugin:

Headings become columns. Tasks become draggable cards.

Drag-and-drop updates the underlying Markdown file. The source remains plain text.
The same file can render as:

• Outline view

• Table view

• Kanban view

The interface changes. The file remains stable.
Separating data from interface is the core design principle.

The Architectural Advantage of Files

Storing tasks as Markdown provides:

• Tool independence

• Optional Git-based version control

• Cross-project searchability

• Long-term durability

• Easier migration

• No AI friction

More importantly, it creates structured surface area that AI systems can operate on directly.

A proprietary task database requires API integration.
A Markdown task file is immediately readable as text within your authorized environment.

Knowledge workers dream or nightmare? When AI has visibility into your workflows, it becomes operational, not conversational.

Layering AI on Top of Structured Task Files

With structured text, AI interaction becomes straightforward.

An AI system can:

• Parse headings as states

• Count incomplete tasks

• Detect overdue items if timestamps exist

• Summarize by section

• Generate reports across multiple files

For example: “Scan all project task files. List open tasks grouped by project. Identify items moved to Done this week. Generate an executive summary.”

If tasks live in separate app silos, this requires multiple integrations, if tasks live in structured files, it is direct text processing.
This model can be described in four layers:

Foundation: Structured Markdown task files
Intelligence: AI systems with read and write access
Logic: Naming conventions and folder standards
Experience: Rendering tools and plugins

Consistency is critical. Automation depends on predictable structure.

A detailed description of this framework is available here:
https://researchanalytics.substack.com/i/187284329/the-file-framework

The AI Parallel: Where We Actually Are

The current state of AI adoption resembles early computing.

(Source:
https://softwareg.com.au/en-us/blogs/computer-hardware/history-of-computer-hardware-timeline?srsltid=AfmBOoorqtVSWJ4OnFJnj_g2ivdRz8cL-hrr9_JWuTovk2tFDSOGOu7-)

Early computers were powerful but isolated. Scale came from standardized operating systems and file systems.

Today, many professionals use AI daily but only through chat interfaces. That is comparable to early computing before standardized file layers.

The breakthrough in computing was structured, portable foundations.

The same principle applies here, if tasks remain inside proprietary systems, AI remains peripheral. If tasks exist as structured files, AI becomes operational.

Getting Started

1. Create a .md file (or even just a .txt file) for a project.

2. Define workflow states as second-level headings.

3. Add tasks using checkbox syntax.

4. Store the file in a shared or version-controlled repository.

5. Use a Markdown-aware editor to render views.

6. Introduce AI summarization once structure is stable.

Start small. Enforce consistency. Avoid premature complexity.

You can drag and drop a Markdown file directly into your AI system and begin querying it.

This also works with Word documents or exports from other tools. Each conversion step adds friction.
The objective is direct access to source files.

No copy-paste loops. No intermediary formats. No proprietary lock-in.

Structured text becomes the system of record.

Conclusion: Files First

Markdown does not replace enterprise tools overnight. It establishes a portable layer beneath them.

In early computing, progress came from standardized file systems and durable abstractions that separated data from interface.

AI is at a similar stage. Many professionals use AI. Few have redesigned workflows so AI can operate directly on core artifacts.

Build the foundation first.

If tasks live inside proprietary databases, their is too much friction between you and AI. If tasks live as structured files, AI becomes an operational layer.

The shift is not about better prompts, it is about better foundations.

Markdown Task

Here are the task used to make the images in this blog post, copy/paste them into the markdown editor of your choice.

## Phase 1: Foundations & Data
- [x] **Gather Report Requirements**
	* [x] Define KPIs and target audience
	* [x] Identify data sources (SQL Server, Excel, API)
- [x] **Data Architecture**
	* [x] Establish Power Query transformation logic
	* [x] Create Date Table (DAX or M)
- [ ] **Security Mapping**
	* [x] Define Row-Level Security (RLS) roles
	* [ ] Map users to security groups in Entra ID
## Phase 2: Design & Build
- [x] **Data Modeling**
	* [x] Build Star Schema (Facts and Dimensions)
	* [x] Create Core Measures (Total Sales, YoY Growth)
- [ ] **Report Visualizations**
	* [x] Create "Executive Summary" landing page
	* [ ] Build "Drill-through" detail pages
	* [ ] Apply corporate branding and color themes
## Phase 3: Deployment Pipeline
- [x] **Deploy to Development**
	* [ ] **Deploy to Test**
	* [ ] Validate data refresh schedules
	* [ ] Set up Gateway connections
- [ ] **Deploy to Production**
## Phase 4: Enablement
- [ ] Create "Data Dictionary" for business terms
- [ ] **User Documentation**
- [ ] Record 5-minute "How to Navigate" video
- [ ] **Final Sign-off**

Power BI analytics has become too complex for informal documentation and basic file versioning. The PBIP format exposes report logic as text, making real version control possible. GitHub provides a clear history of changes, decisions, and ownership, even for solo analysts. Because it is text and Markdown based, it also integrates cleanly with modern AI tools. Together, Power BI and GitHub bring software grade discipline to higher ed analytics without turning analysts into software engineers.

Leveraging GitHub with Analytics Reporting

Overview

As discussed in this post, university analytics teams can learn a great deal from software developers. Software teams routinely manage hundreds or thousands of lines of logic while maintaining documentation, version control, and a clear record of decisions.

The core question is straightforward. How do large groups of people work on the same system without losing track of changes, intent, and ownership?

GitHub is the industry standard answer. While many higher ed analysts do not consider themselves software developers, the overlap between analytics work and software development is substantial.

Version Control Without GitHub

Most analytics teams already use a form of version control without realizing it. Every time a file is saved to OneDrive or Google Drive, a new version is created. This allows basic rollback and recovery.

That approach works at the file level, but it breaks down when you need to understand how logic changed over time or why a decision was made.

Power BI Project Format (PBIP)

Historically, Power BI stored everything in a single PBIX file. Data, transformations, the model, calculations, and metadata were bundled together. This made meaningful version control nearly impossible.

The PBIP format changes this by breaking the report into a structured folder.

There are four main components. The data itself is stored in the fourth folder under .pbi, which acts as a local cache. GitHub does not upload this data. Only the report structure and logic are tracked.

All elements of the PBIP format are human readable text. This makes them suitable for inspection and version control. This approach is consistent with modern Microsoft file formats. If you have ever renamed a .docx file to .zip, you have seen the same underlying structure.

GitHub Integration

The simplest way to get started is GitHub Desktop. While command line tools are available, GitHub Desktop lowers the barrier significantly.

You will need a GitHub account. Many institutions already have higher education agreements that support single sign on. If not, a personal account works. No data is stored in GitHub, only the report structure.

Even for solo analysts, this setup is valuable. GitHub provides history, accountability, and documentation by default.

Instructions for connecting a local PBIP folder to GitHub are available here:
Adding a repository from your local computer to GitHub Desktop

GitHub tracks text changes over time. To the user, it looks like a normal folder. Behind the scenes, GitHub records:

• Which files changed

• What lines were added, modified, or removed

• When the change occurred

• Who made the change

Each sync, or commit, includes a short description such as “Updated ROI calculations.” Commits can also be linked to issues. When an issue is referenced, it is automatically closed, creating a direct connection between tasks and changes.

Saving Power BI Reports as PBIP

Saving reports in PBIP format must be enabled in Power BI preview settings. Publishing to workspaces works the same way as before.

When first enabling this feature, creating backups is strongly recommended, especially if you are using deployment pipelines.

Conclusion

Higher ed analytics has outgrown informal documentation and file based versioning. As complexity increases, the cost of lost context rises quickly.

GitHub addresses this directly by providing a clear, auditable history of changes and decisions. With PBIP, analytics logic is no longer trapped in opaque files. It becomes visible, reviewable, and manageable.

This workflow is not only for large teams. Even if you are a team of one, GitHub becomes your documentation, change log, and long term memory. It reduces rework today and lowers the cost of collaboration tomorrow.

Because GitHub is Markdown and text based, it also integrates naturally with modern AI tools that operate on structure and context. As analytics and automation continue to converge, this is a meaningful advantage.

This is not about turning analysts into software engineers. It is about using the right infrastructure for complex analytical work.

TLDR: AI feels underwhelming because your work is trapped across too many disconnected tools. The next wave of value comes when AI can operate directly on structured work data.

AI Feels Useless Because Your Work Is Locked Away

If AI is truly as “magical” as they say, why haven’t your own efforts to use it been impressive? Why does it feel like more fuss than it is worth?

Let’s be honest: this image is a typical week for most people whose job happens on a laptop. Emails. Meetings. Spreadsheets. Logins. Status updates. Repeated follow-ups.

How can AI help us right now, using what we already have access to today, within the confines of organizational security protocols?

Here is the core problem.

Most knowledge work is fragmented across too many tools that do not talk to each other. The work you need is buried behind logins, dashboards, and scattered files.

AI is not failing because it is weak.

AI feels weak because it cannot see your work.

The FILE Framework

To build an AI-ready productivity system, we use the FILE framework. It is a personal layer that complements official systems of record, not a replacement for them.

F: Foundation (The Filesystem)

Your work lives in folders of plain-text Markdown (.md) files for notes, tasks, and logs.

I: Intelligence (The Models)

LLMs reason over your foundation. Today it might be GPT-4o or Claude. Tomorrow it will be something else.

L: Logic (The Orchestration)

This is where automation lives. It turns daily logs into weekly updates, extracts tasks, and flags project risk.

E: Experience (The Interface)

This is how you interact with the system: Obsidian, VS Code, or any other editor. The interface is interchangeable.

Why Markdown Works

Markdown is a practical interoperability layer, it is a simple text based file format, much the same as a .txt file but with well defined formatting standards for things such as headings, tables, links etc.

https://www.markdownguide.org/getting-started/

It is readable for humans, easy for machines to parse, and stable over time.

It also avoids a core problem with most productivity systems: your work becomes trapped inside proprietary databases.

A Concrete Example: The Weekly Status Report

Instead of manually maintaining a project dashboard, keep one Markdown project file that includes:

• Scope

• Tasks

• Decisions

• A running log of updates

At the end of the week, upload that file to an AI and ask:

• What changed this week?

• What are the top 3 risks?

• What tasks are blocked and why?

• What decisions were made?

• What should next week’s priorities be?

If the AI cannot answer, that is not a failure. It is a diagnostic.

The First Steps

1. Create one Microsoft Word file for your next project with headings for Scope, Tasks, Decisions, and Log.

2. Upload it to an AI and ask it to behave like a project manager.

3. Each time the AI cannot answer a question, update the file so the information exists next time.

Final Thought

Stop optimizing applications. Start optimizing for data.

Files first. Single self contained MS Word (or Markdown if you are feeling brave) file for each project, task, notes, scope etc..

AI on top.

“Talk” to your notes by dropping them in your authorized AI tool.

The winners will not have better prompts. They will have better data.

NOTE: This is a shorter version of my original text which can be found here, Listen to a summarized version here

Overview: AI feels underwhelming because your work is trapped across too many disconnected tools. The next wave of value comes when AI can operate directly on structured work data.

TL;DR: To move beyond static reports and manual spreadsheets, universities must treat analytics as a software engineering discipline. This requires a unified pipeline where data is ingested, modeled, versioned in GitHub, and deployed securely.

A modern university analytics ecosystem integrates data from core operational platforms into a single, scalable workflow. It transforms raw, siloed information into reliable strategic insights that leadership can trust.

The Challenge: Unifying the University

Universities depend on several major data domains to support analytics, compliance, and strategic planning. Bringing these traditionally gated systems into a single “source of truth” is the primary challenge of higher ed analytics.

The raw inputs for this lifecycle come from the following data domains. Each with its own security, culture, documentation, and last but not least, political landscape:

• Student Information Systems (Enrollment, retention)

• HR and Workforce (Faculty effort, staffing)

• Sponsored Research (Grants, eRA activity)

• Finance (General ledger, accounting)

• Infrastructure (Space utilization)

• Faculty Activity (Publications, awards)

The Solution: A Unified Lifecycle

To turn these siloed sources into insight, we need a structured lifecycle. Here is an example framework.

The Ingestion Pipeline (The Intake)

All institutional dataflow starts here. Whether using Microsoft Fabric Dataflows, Tableau Prep, or custom ETL tools, the goal is identical: extraction, transformation, and normalization.

• The Goal: Move from “manual exports” to repeatable, automated pipelines.

• The Result: A clean, standardized foundation where the data is trusted before it ever reaches a report.

The Data Model (The Brain)

Once data is ingested, it must be shaped. In this layer, often a Microsoft semantic model or Tableau logical layer, we merge systems and define rules and calculations. This is where we establish cross‑system relationships, standardize definitions, and ensure consistency across domains.

We build measures, calculated columns, parameters, date tables, and time‑intelligence functions. In Power BI, the data model combined with DAX (Data Analysis Expressions) is a powerful expression language. Instead of looping through rows or merging datasets like in R, Python, or SAS, DAX creates calculated measures that operate across related tables without physically merging data.

• Why it matters: This ensures that “Research Expenditure” means the exact same thing in the College of Engineering as it does in the Provost’s office.

GitHub and Code Management (The Governance)

This is the differentiator between a “spreadsheet culture” and an “engineering culture.” Even though tools like Power BI are low-code, the logic governing them should be treated like software. We use GitHub to separate the logic (report definitions, transformations) from the data (student records, financials, sponsored research, HR data etc.).

GitHub allows us to:

• Version Control: Roll back to previous versions if a metric breaks.

• Collaborate: Use branching and pull requests to manage changes safely.

• Secure: Keep logic public/shared while keeping sensitive university data locked down.

For a deeper dive on how to use GitHub to manage projects (without writing code), read Part 1 of my series here.

The Deployment Pipeline (The Release)

We never want to push changes directly to the production set of dashboards. Instead, we use a structured pipeline:

• Development: Where we build and experiment.

• Test: Where we validate accuracy with stakeholders.

• Production: The live environment for decision-makers.

This ensures rigorous quality assurance and predictable updates.

Balancing Central vs. Local: The Unit-Level Ecosystem

A campus-wide system is powerful, but it can be slow. A major operational unit such as Research, Finance, or a large College needs to move faster.

We need both campus level and Unit-Level Analytics Environments to be truly agile. Just as colleges and operational units have unique strategic plans and priorities, they also need specialized versions of the main lifecycle that allow specific teams to:

• Iterate Quickly: Respond to operational needs in real-time.

• Specialize: Build models aligned with deep domain expertise (e.g., bibliometrics for Research).

• Experiment: Try new things without waiting for a campus-wide release.

This structure allows the university to have a “central truth” while empowering units to have “local agility.”

The Output: Decision-Ready Analytics

Ultimately, the technology serves the user. The production models feed downstream tools like Power BI, SharePoint, and Teams. This is where the work pays off, enabling:

• Operational reporting for managers.

• Executive dashboards for Deans and VPs.

• Scenario modeling (”What if we increase grant targets by 10%?”).

• Research collaboration insights.

To see how we implement these models technically, read my article on Elevating Strategic Metrics with Power BI and Cloud Integration.

Conclusion

This is more than a technical workflow; it is a strategic analytic framework. A modern analytics ecosystem only becomes valuable when its insights reach the people who make decisions. To get there, institutions must invest in a coordinated strategy to export, centralize, and unify data from traditionally siloed systems.

By adopting this framework, universities create a scalable, trusted foundation that empowers leadership to make decisions based on a single, consistent truth.

Higher ed analytics is drowning in scattered communication, fragile workflows, inconsistent documentation, and version chaos. A GitHub-centered workflow eliminates these failures by providing structure, visibility, decision history, and reproducibility across units and reporting cycles.

Introduction

If you work in university analytics, whether you’re leading the operation or grinding through the data, you already know the pattern.

Every reporting cycle unleashes the same chaos: duplicated files, contradictory numbers, forgotten decisions, missing documentation, shifting definitions, and eleventh-hour surprises.

HERD. IPEDS. Finance. HR. Tuition. Space. No domain is spared.

Leaders carry the burden of accuracy and defensibility. Analysts carry the burden of execution under unrealistic timelines. Both are trapped inside workflows built for a simpler era before current volume, complexity, and governance demands existed.

The truth: higher ed analytics is running on outdated tools, and the cracks show more every year.

Other industries solved these problems years ago.

They moved their analytical workflow onto GitHub not because it’s a coding tool, but because it offers structure, visibility, accountability, and historical traceability that shared drives and email chains will never replicate.

Before the solution, let’s look at the chaos leaders and analyst are currently forced to manage.

The Email That Triggers the Fire Drill

Here’s a fictional but painfully familiar email about the HERD Expenditures Report. If you work anywhere near this process, you’ve lived some version of this message. It drags multiple units into a scramble: finance, research administration, departments, space planning, IT, and anyone else owning part of the data trail.

You may be the one sending this email to your team, or one of the people this email is sent to, either way, the pain points are the same

Subject: Issues to Resolve Before Submitting HERD Expenditures Report

Team, after reviewing the draft HERD Expenditures Report, I found several issues that must be resolved before submission:

• FY data gap in Organized Research. Misclassification of interdisciplinary center activity. Inconsistent handling of cost share (zeros vs blanks)

• Missing functional classifications. No drill-through from summary to project detail. Confusing FY comparison filters. Incorrect inclusion of service center revenue

• Equipment purchases not flagged correctly. Documentation references wrong overhead methodology. Undefined acronyms in the documentation

Thanks

Each bullet can require a different unit, domain expert, or system owner. And this is probably one of several major projects on your plate. If you’re in leadership, this might be one of dozens, each with its own tangled email chains, outdated file versions, and undocumented decisions.

How Do You Track Multi-Unit Work With Email and Shared Drives?

Short answer: you don’t. Not without losing visibility, accuracy, or your sanity.

Multi-unit issues generate splintered threads, inconsistent attachments, dropped CCs, and contradictory versions of truth. Nobody knows what’s complete, what’s blocked, or what was decided three days ago.

Microsoft Teams is rolling out true threaded conversations, which is a major improvement for multi-stream discussions, but rollout across higher ed is slow and inconsistent. But rollout across higher ed is slow and inconsistent. As long as institutions are on fragmented versions of Teams, it can’t serve as the backbone of multi-unit issue tracking.

Meanwhile, leaders are forced to reconstruct the big picture manually: digging through emails, reconciling mismatched documents, and trying to reverse-engineer logic that lives only in someone’s head.

What Email-Based Workflows Produce

The problem isn’t the people, it’s the workflow.

The Legacy Workflow Leaders Are Forced to Navigate

Here is a structured snapshot of the legacy workflow, organized as a table to make the failure points impossible to ignore. Each row reflects a systemic weakness that compounds during every reporting cycle.

What You Actually Need

Before picking tools, you need clarity on requirements. Any viable system must:

• Track every change across units and reporting cycles

• Document the logic behind decisions, not just the final numbers

• Preserve history so nothing depends on memory

• Give leaders and analysts real-time visibility into progress, blockers, and ownership

• Guarantee reproducibility for next year’s cycle

• Enable collaborative review without losing context.

If a system can’t do these things, the above example will compound and repeat foreach, and every project!

How Non-Academic Sectors Manage Complex, Large-Scale Workflows

How is this done in the “real-world” where teams may be hundreds if not thousands of people. As an example, the Microsoft Windows operating system has around 50 million , that is 50,000,000 lines of code with various parts being worked on by teams of people, version control, documentation, issue tracking, and project management.

How do large companies such as these manage their data, code, and reporting projects……Github that’s how

Conclusion

Now that the problem is defined, the next step is straightforward: show how GitHub provides the structure, visibility, and historical traceability that higher ed analytics has been missing. It supports the big picture for leadership, the coordination layer for project managers, and the detailed work for analysts, all inside a single coherent workflow. That’s how teams stop chasing emails and start managing real progress.

This framework is an essential part of the journey to become a navy seal of data analytics.

To close this out, higher ed doesn’t need more heroics from analysts or more manual oversight from leaders. It needs systems that scale. GitHub already powers some of the largest, most complex, most audited workflows on the planet. There is no reason higher ed can’t operate with the same discipline, the same clarity, and the same confidence.

Next up: How to actually use GitHub to bring order, visibility, and repeatability to higher ed analytics workflows

In a land not so far away, on a campus you call home, an unforeseen data war is raging. It’s a fierce battle between the relentless, ever-growing hordes of data and the valiant forces of analytics. Every day, the data grows stronger, multiplying by the hour. If you’re not actively gaining control over your data, it’s gaining ground, plotting to overwhelm your spreadsheets, outmaneuver your dashboards, and overwhelm your analysts. It is constantly evolving, requiring you to learn new ways to battle it, whether this is the latest analytics updates, a new cloud-based data lake, or finally deciphering the ancient runes of your predecessor’s undocumented code. So arm yourselves with your most potent algorithms and bravest pivot tables, because in this war, only the most insightful will prevail!

The Data War Army

Standard analytics groups serve as the backbone of the university’s data operations, akin to the disciplined infantry in military strategies. Their roles encompass reporting, data governance, security, and adherence to institutional policies. Standard reporting units within this group ensure consistent and accurate data dissemination throughout the organization. The thorough and meticulous nature of their processes is crucial for maintaining data integrity and institutional stability. However, this rigorous approach often results in slower adaptation to new technologies and delays in addressing urgent data needs.

The Data War Special Operators

Navy SEALs and other specialized units are often deployed behind enemy lines to conduct foundational operations and reconnaissance. These groups undergo extensive training that significantly surpasses the standard military preparation, equipping them with specialized skills crucial for their missions. The necessity for such elite units stems from the inherent limitations within conventional military forces, which, by their very nature, lack the agility and rapid response capabilities required in certain critical scenarios. This distinction underscores the strategic deployment of specialized forces in operations where speed, stealth, and precision are paramount.

Rapid Response Units

In contrast, the rapid response units within the STRIKE framework are the elite Navy SEALs of data analytics. These teams are characterized by their agility, advanced skill sets, and ability to deliver swift, actionable results. They are specifically deployed to tackle immediate, critical data requirements and excel at quickly integrating new technologies and solutions. Operating efficiently behind the scenes, these units lay the groundwork for broader institutional initiatives, enabling the university to promptly address emerging challenges and seize new opportunities.

STRIKE | Specialized Transformative Results through Insights & Knowledge Extraction

The Imperative for Both Groups

University leadership must recognize that both groups are indispensable for a comprehensive and successful data analytics strategy. Standard reporting and IT deployment teams provide the foundational stability required for robust data management, ensuring that all analytics activities are secure, compliant, and accurate. Nonetheless, an exclusive reliance on these teams can result in slow and unsatisfactory outcomes, as their processes are inherently not designed for rapid execution.

Conversely, the rapid response units infuse the necessary agility and speed to meet urgent data demands and foster innovation. By incorporating both groups, universities can maintain a solid data infrastructure while simultaneously enabling swift and effective responses to new demands and opportunities.

The Common Pitfall: Single Group Utilization

A prevalent mistake within many institutions is the attempt to utilize a single group to fulfill both roles. This approach typically leads to slow, inefficient, and often frustrating outcomes. Standard teams, by their very nature, are not equipped to be agile, or manage rapid deployment and immediate problem-solving, resulting in significant delays and operational bottlenecks.

The synergy of both groups working in tandem is paramount to managing data effectively while also fostering innovation and rapid response to challenges.

Conclusion

The STRIKE methodology—through its dual approach—leverages the strengths of both standard teams and rapid response units, ensuring a more efficient, effective, and innovative use of data across the institution. By understanding and embracing the distinct roles and capabilities of each group, university leadership can optimize their data analytics strategy and enhance the institution's overall performance and responsiveness.