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. A fitting solution was sitting on the shelf – a sales-assistant app with CRM features that we had developed ourselves, able to analyze company websites, detect signals and draft outreach. We did not use it.

The job went to a folder of Markdown files.

A Markdown file is a plain text file with some structure: headings, lists, links. 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 consists of 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 is written quickly – for us it was one afternoon – and tried on real cases; an application is not. The order itself is therefore the win – the text file first, and the code only if the experiment fails.

Four of our own tools, tested

The clearest result came from sales research. The app could do much of what our weekly research needs, and it still lost. The instruction in text form could be adjusted in minutes whenever our criteria changed; one example dossier was enough to show the agent the desired shape. The same changes in the app would have meant development work, from new fields up to the next deployment. What remains, to name it honestly, is an interface: a team that does not work with agents itself would rather click through an application with views and statuses than maintain text files. For such a team the app stays the right choice. For us it was not.

The test went similarly for our briefings. Every morning at 6 a.m., a small service sends our internal news briefing; the actual editorial work lives in a single configuration file – which topics interest us, which sources are read and what stays excluded. The code around it fetches articles, removes duplicates and sends an email. It is deliberately thin, because the value lies in the editorial configuration, which a subject-matter person can change without programming.

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. We are currently building an application that checks 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 that survive a crash, budget limits per run, stored evidence for every AI answer, and reports that can still be traced weeks later). As soon as external users are meant to use a tool without us, the text file stops being enough.

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.

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?

A rule from our own work, recorded in our internal sales handbook since August 2026: every piece of software first has to prove itself against a text file. That a company earning its money with software development decides this way is not a contradiction but the principle of the smallest useful solution taken seriously – we recommend custom software where authoritative data, roles or long-term operation justify it, and only there.

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.

If you are facing a decision like this right now, bring the workflow and a few real examples from your business – then we can discuss a concrete workflow and check together whether software really has to come first.