Software or a Markdown File: How We Decide

In August 2026 we rebuilt our own prospect research: roughly 1,900 companies from three trade-fair exhibitor lists, a handful of thoroughly researched dossiers every week. We knew a fitting solution well: a sales-assistant app with CRM features that we built for a client, where it runs in daily sales work. It reads company websites, detects signals and drafts outreach. For our own research we still did not set up a second instance of it.

The job went to a folder of Markdown files.

A Markdown file is a plain text file with a little structure. Headings, lists and links are enough. For an AI agent it becomes a work instruction: which sources it may use, which rules it applies, what the result should look like and where its boundaries lie. Together with a standard CRM (we use Twenty at 9 dollars per month), this combination now does work for which we would previously have built our own application. Since then, we have put every tool decision, our own as well as our clients', through the same test.

The Markdown test

The test has a single question. Can a text file with an AI agent do the same job as reliably as the planned software? The honest way to answer it is with an experiment rather than an estimate. A work instruction can be tried on real cases before an application exists. The order itself is therefore the win: the text file first, and the code only if the experiment fails.

Four parts that do not have to stay together

An internal tool has four parts. The engine does the work. Memory holds data and rules. The trigger decides when something starts. The interface shows people the result and accepts their input. Conventional software joins all four in one application. An AI agent can separate them: it works as the engine, reads a text file as its rulebook, starts on a schedule or request, and delivers the result where it is needed.

In our prospect research, the agent is the engine, Twenty holds companies and status, a weekly task is the trigger, and dossiers plus CRM entries form the interface. We did not need a custom app for this workflow. That breakdown is more useful than the broad question of whether a company needs “software or AI.”

Four tools, tested

The clearest result came from sales research. The app can do much of what our weekly research needs. At the client it is the right form, because a sales team that does not work in a terminal uses it there and reviews and sends every outreach from Outlook. For our own team, which works with agents anyway, the text file was the smaller solution: we could change the instruction directly whenever our criteria shifted; one example dossier showed the agent the desired shape. The same changes in an app would have meant development work, from new fields up to the next deployment.

The test was just as clear for our briefings. Fetching, selection and delivery are still spread across two services today. The editorial choices belong in one configuration file that records topics, sources and exclusions and can be changed without programming. The two services should therefore shrink to thin code for fetching, deduplication and delivery.

For the third tool, our own agent operations, the text file was central from the start. Policies, work instructions and review rules are prose; agents read them and do the work, and a person approves before anything leaves the company. Software exists here too, but only as a thin layer, for example for mailboxes and access rights.

Only one tool decided the test clearly in favor of software. Our visibility-check application examines whether AI systems such as ChatGPT or Perplexity recommend a company when buyers ask for suitable suppliers. A single check of that kind could be done by an agent in one session. The application exists for something else: the same check for many companies, unattended and repeatable, with durable workflows, budget limits per run, stored evidence, and reports that remain traceable later. As soon as other people are meant to use a tool without us, the text file stops being enough.

Nobody but us works in a terminal

We work with agents and text files in a terminal. Clients and their teams usually do not. The interface is therefore not an afterthought; it simply does not have to be a custom app from the start. Five levels cover most internal tools:

1. A finished result arrives as an email, report or page. Nobody operates the tool directly.
2. The agent works in a familiar channel and can pick up replies there.
3. A small web form collects a few fixed inputs and returns a result.
4. A shared AI workspace such as Claude Cowork or ChatGPT gives a team access to instructions and files.
5. A custom application coordinates several users, authoritative state and immediate feedback.

These levels are not maturity stages. For a daily briefing, an email is often a better interface than a dashboard. The right level depends on who uses the result, what that person may change, and how costly a misunderstanding would be.

When software wins the test

• The workflow creates authoritative data whose errors would be expensive, such as quotes, inventory or approvals.
• External users are meant to serve themselves, at a volume nobody supervises on the side.
• Operation needs hard limits, for example a cost budget per run or volume caps that even a good agent cannot guarantee.
• Results must be stored as evidence and remain traceable later.
• A team needs a stable daily interface and does not work with agents itself.
• Several people change the same state at once or need immediate feedback, including with a weak connection.

Often, however, the test does not end in either-or. The best shape is then a combination in which the app remains the system that owns the authoritative data and rules, while the agent works inside it as the execution layer: it reads, prepares, checks exceptions, a person approves; anyone building a new application therefore makes it agent-ready from the start.

How many of these points need to apply depends on the risk; a fixed number would be dishonest. The wider picture, from off-the-shelf tools through AI agents to an owned application, is laid out in Automate Business Processes.

Five questions for your next tool decision

1. Who besides you is meant to use the tool, and would that person maintain a text file?
2. Does it have to run unattended, or does a person review every result before it becomes binding?
3. Does it write authoritative data, or does it prepare drafts?
4. How often do the rules change? Frequent changes favor text that subject-matter people adjust themselves.
5. What does a mistake cost: an awkward email phrasing or an incorrect invoice?

Our review of four tools led to a firm rule in August 2026: every piece of software first has to prove itself against a text file. A company that earns its money with software development can make that decision without contradiction; it is the principle of the smallest useful solution taken seriously. Custom software fits where authoritative data, roles or long-term operation justify it. The XPO Inventory project shows such a case: the application connects inventory, project status and several roles in one workflow: read the case study.

This article deliberately leaves two things open. How an agent accesses production systems safely is a topic of its own and beyond this scope. And whether our text files will still be enough in two years, we do not know; the test is repeatable, and that is exactly what we rely on.

For your next decision, take one real workflow and write down its engine, memory, trigger and interface separately. Then choose the smallest interface level that fits its users and the cost of error. When uncertain, begin one level lower: expanding a tool is easier than dismantling an unnecessary application.