AI Ready
Programs card, MethodKit for AI Readiness
Card 23 of 48 · MethodKit for AI Readiness
  • ThemeYour Setup
  • CardCard 23 of 48
  • Questions5 to explore
Your Setup

Programs

Software & apps you run on

The desktop and mobile software your team runs every day shapes what kinds of work an AI can join, because a tool can only participate in what happens inside software it can connect to or read from.

Programs fall into two very different categories when it comes to AI readiness: those that live in a browser or have an API, and those that run locally on a machine with no external interface. A design file in a native desktop application, a spreadsheet saved to a local drive, or a specialized industry tool that predates cloud computing can all be invisible to a web-connected AI tool.

The more interesting question is not just which programs you use, but what output those programs produce and where it goes. A program that saves to a shared cloud folder becomes reachable. One that saves only to a local drive, or that uses a proprietary format no other tool can read, is effectively locked away. Getting a clear view of which programs produce reachable output is a quick way to map what is already accessible.

Make it visibleList the five programs your team uses most, then for each one note where its output ends up: local drive, shared folder, or proprietary format only. That list tells you which programs are already reachable and which ones need a bridge.

Why AI needs this

Each part of your work matters to AI in a specific way. Some of it is context a tool needs before it can help, some of it is work a tool can take on, and some of it is judgment that should stay with you.

Cloud versus local output

Programs that save to cloud storage are accessible without extra work. Programs that save only to local drives put the output out of reach until someone moves it.

Proprietary file formats

Some software writes files only it can open. An AI cannot read those files unless you export to a common format first, which often loses structure or fidelity.

Version differences across the team

When team members run different versions of the same program, the files they produce may not be fully compatible, creating silent inconsistencies that compound when feeding output to an AI.

Questions to explore

Use these on your own or in a group. There are no right answers, only better conversations.

  1. Which programs does your team use every day, and which of those save their output somewhere accessible?

  2. Are there programs that produce files only one person on the team can open or export?

  3. Which programs do you rely on that have no API, no integration, and no easy export path?

  4. How often does your team move files from a program into shared storage, and is that a habit or an afterthought?

  5. Are there legacy programs the team still depends on that have no modern equivalent or integration path?

Readiness traps

  • Specialized industry software often stores its data in proprietary formats or internal databases. The output may look like a file, but extracting structured data from it can be a significant technical project.
  • Programs installed on one person's machine create a single point of failure: if they leave, or the machine is unavailable, the work in that software may be inaccessible to anyone else.
  • Software that runs entirely offline offers no integration surface. Before assuming a program can be connected, verify whether it has ever been designed to communicate with anything outside itself.