TL;DR: The CRA platform already records when you became aware. The readiness gap is internal: awareness evidence, named ownership and a clock you can defend.

If your company puts a product with digital elements on the European market, a reporting obligation has been running since 11 September 2026. On that date the Cyber Resilience Act reporting duties under Article 14 became applicable, and the Single Reporting Platform operated by the European Union Agency for Cybersecurity went live to receive the filings.

The common reading of this is a tooling problem: a new portal, a form to learn, an integration to build. That reading gets the difficulty backwards. The platform is straightforward and it already records the thing that matters most, including a field for the date and time you became aware of the incident or the actively exploited vulnerability.

Why this matters: every deadline in Article 14 is measured from your awareness, not from the platform, not from a customer complaint, and not from the moment somebody senior finds out. So the readiness question is not whether you can use a portal under pressure. It is whether you can say, with evidence, when you became aware, prove it months later, and get a filing submitted within 24 hours by a named person who is not asleep. Most of that work sits inside your own organisation, and none of it can be bought.

This is a readiness diagnostic, not legal advice. It ends in one of four verdicts: OUT_OF_SCOPE, READY, GAPS, or NOT_READY. For how the obligations should be interpreted for your specific products, the European Commission publishes implementation guidance, and where the stakes are high this is a question for your own counsel.

What Article 14 actually obliges, and from when

The current published deadlines form a cascade, and each stage starts from awareness rather than from the previous filing:

• Early warning: without undue delay and in any case within 24 hours of becoming aware of the actively exploited vulnerability or severe incident.
• Notification: without undue delay and in any case within 72 hours of becoming aware, carrying general information and an initial assessment.
• Final report: for an actively exploited vulnerability, no later than 14 days after a corrective or mitigating measure such as a patch becomes available. For a severe incident, within 1 month after the 72-hour notification.

Filings go through the platform, where the submitter selects the relevant national computer security incident response team designated as coordinator. Not every field is required at every stage: some that are optional in the 24-hour early warning become required in the 72-hour notification or in the final report, which is a detail worth knowing before the clock is running rather than during.

One scope point is easy to miss. The reporting duty applies from 11 September 2026 to products with digital elements that fall within scope, including products that were already on the market, rather than only to things you ship from now on. Your installed base is in scope, which for most companies is the larger surface.

The counter on the platform is not your legal clock

Here is the detail that most readiness checklists have not caught up with, and it is documented openly in the platform's own published answers.

In the current release, the 72-hour counter displays a due date and time 48 hours after you submit the 24-hour early warning, rather than 72 hours after you became aware. The consequence is stated plainly: in some cases a notification may be displayed as overdue before 72 hours have actually elapsed since awareness. The operator has said this logic will be updated in a future release to calculate the deadline from the awareness field instead, for both actively exploited vulnerabilities and severe incidents. For actively exploited vulnerabilities, a final-report counter is not currently implemented at all.

Two practical consequences follow, and both are about your own discipline rather than the tool:

1. Do not let a screen define your obligation. Your legal deadline runs from awareness. Track it yourself, from your own recorded timestamp, and treat any on-screen counter as a convenience that may currently be conservative or absent.
2. File the early warning early, not at hour 23. Because the displayed 72-hour deadline is derived from when you submitted the early warning, a late first filing compresses the window the platform shows you for the second one. Submitting promptly costs nothing and removes an entirely self-inflicted squeeze.

Neither point is a criticism of the platform. It is a young system, its operator has documented the current behaviour and the intended change, and reading that documentation is part of being ready.

Test 1: Are you in scope, and as what?

Scope and role come before every other question. Are you a manufacturer of a product with digital elements, or are you a distributor, an importer, or the steward of an open-source project, each of which carries a different position? A company that only uses software is in a different situation from one that ships it.

Write down each product you place on the market, including the ones you inherited through an acquisition or maintain for a single large customer, and state your role for each. If this list does not exist, it is the first thing to build, because you cannot report on an inventory you do not have. If nothing you do places a product with digital elements on the market, your verdict is OUT_OF_SCOPE and you can stop here with that written down and dated.

Test 2: When exactly did you become aware, and who says so?

This is the test that decides most outcomes, and it is almost entirely an internal evidence question.

Awareness arrives through unglamorous channels: a support ticket, an alert, a security researcher's email, a customer telephone call, a post on a forum, a monitoring threshold. Ask what your timestamp would be if you had to defend it a year later. Which record is authoritative, what time zone is it in, and does it survive a ticket being reassigned, merged, or closed and reopened?

Then ask the harder version. If a support engineer received a credible report on Friday afternoon and it reached the security owner on Monday, when did the company become aware? Decide that rule in advance, write it down, and make the recording of it automatic rather than a matter of someone's memory. The platform gives you a field for this timestamp; what it cannot give you is a defensible basis for the value you type into it.

Test 3: Who owns the 24-hour filing, at 02:00 on a Sunday?

Twenty-four hours is a real constraint for a company of twenty to fifty people, where the CTO, the COO and the founder are often three names on the same short escalation list. Name the accountable person and at least two deputies, and make sure each is registered on the platform and has actually logged in before an incident, not during one. An access problem discovered at hour 20 is an avoidable failure.

Rehearse one filing end to end against a fabricated scenario. You are looking for the boring obstacles: who can approve saying something publicly consequential, who reviews wording that admits active exploitation, what happens when the named owner is on holiday, and how the deputies find out they are now responsible. A rehearsal that takes an afternoon reliably finds two or three of these.

Our incident response playbook for European SMEs covers the internal escalation mechanics this depends on, and the NIS2 compliance guide covers the adjacent regime, which is a different duty: NIS2 reporting attaches to you as an operating entity, while Article 14 here attaches to you as the maker of a product. A company can easily owe both, through different channels, for the same bad weekend.

Test 4: Can you produce the 72-hour assessment without an API?

At the initial release, the platform provides no application programming interface, so notifications are submitted through its interface, and automated bulk submission is not available. Interface support may be considered in a future phase. What you may do, explicitly, is automate your own internal workflows and integrate the reporting requirements into your own systems and records.

That is the correct division of effort. Do not build towards an integration that does not exist yet. Instead make sure that, within 72 hours, you can assemble an initial assessment from evidence you already hold: what is affected and in which versions, what the likely root cause or triggering threat is, what mitigations are applied or under way, and what the severity and impact look like on current information. If producing that means three engineers reading chat history for a day, you have found a real gap, and it is an internal one.

Keep the wording cautious and conditional where the facts are still moving. An initial assessment is explicitly initial, and a final report follows later.

Test 5: What happens after the notification?

Readiness does not end at hour 72. For an actively exploited vulnerability the final report is due no later than 14 days after a corrective or mitigating measure becomes available, which ties your reporting deadline to your release process. If your patch pipeline takes six weeks for a supported older version, that interacts with this obligation in a way worth understanding before it happens.

For a severe incident the final report is due within a month of the 72-hour notification. Note also that a counter is not currently implemented for the actively-exploited-vulnerability final report, so that one is yours to track without help from the screen.

Reading the verdict: OUT_OF_SCOPE, READY, GAPS, NOT_READY

One verdict, dated and written down where decisions are recorded, with the evidence beside it.

OUT_OF_SCOPE when you do not place products with digital elements on the European market in a role that carries the duty. Record the reasoning and the date, and revisit it when you ship something new or acquire a product line.

READY when you have a product inventory with roles, a written awareness rule, an automatic and durable awareness timestamp, a named owner plus registered deputies who have logged in, a rehearsed filing, and the ability to assemble an initial assessment inside 72 hours from evidence you already keep.

GAPS when the obligation is understood and most of the structure exists, but one or two specific things are missing, most commonly the awareness rule or the deputy registration. Name each gap with an owner and a date. This is where most prepared companies honestly sit.

NOT_READY when awareness cannot be timestamped defensibly, or no individual owns a 24-hour filing, or nobody has logged in to the platform. This is not a reason for alarm, but it is a reason to spend the next fortnight on it rather than on something more interesting, because the duty is already live and the first hours of a real event are the worst possible time to discover any of it.

What to put in place this month

Five items, in order, none of which needs new software:

1. The product inventory, with your role for each product and the supported versions.
2. The written awareness rule, including the multi-channel and weekend cases, and where the authoritative timestamp lives.
3. The named owner and two registered deputies, each having logged in to the platform at least once.
4. One rehearsed filing against a fabricated scenario, with the obstacles written down and assigned.
5. An evidence checklist for the 72-hour initial assessment, mapped to systems you already run.

For the current published answers on registration, deadlines, fields and platform behaviour, read the operator's own frequently asked questions for the reporting platform, which is updated as the system is implemented. Check it again before you rely on any specific behaviour described here, including the counter detail above, because the operator has said that part is due to change.

Frequently Asked Questions

Does the platform record when we became aware, or not?

It does. There is a field for the date and time you became aware of the incident or actively exploited vulnerability, so any advice built on the idea that awareness time goes unrecorded is out of date. What is currently true is narrower: the 72-hour counter shown on screen is presently derived from when you submitted the 24-hour early warning, and the operator has said it will be changed to use the awareness field.

We are a small team. Is a 24-hour filing realistic?

It is, but only if the decision structure is settled in advance. The 24-hour early warning is a warning, not a full analysis, and not every field is required at that stage. What makes small teams miss it is not analysis time, it is an unregistered account, an absent approver, or nobody being sure whose job it is.

Do we need to build an integration?

No, and at the initial release you cannot: no interface for automated submission is provided, and filings go through the platform directly. Automate your own internal capture and evidence instead, which is where the work pays off regardless of what the platform later supports.

Is this the same as our NIS2 reporting?

No. They are different duties with different triggers and channels, and they can both apply to the same organisation. Treat them as two obligations that may share evidence, never as one filing.

Related reading

• Incident response playbook for European SMEs, on the internal escalation this depends on.
• NIS2 compliance guide, on the adjacent entity-level regime.
• Compliance monitoring checklist, on keeping obligations observable rather than remembered.

Not sure whether your products are in scope, or whether your awareness timestamp would hold up?

Send the product list, how a report reaches you today, and who would file inside 24 hours. We will tell you whether your position is OUT_OF_SCOPE, READY, GAPS, or NOT_READY, and what the shortest path to READY looks like.

Start with the readiness assessment or write to info@firstaimovers.com.

TL;DR: Five tests that decide whether a dataset, benchmark or prior deployment can carry the decision you have to make, before you build an evaluation on it.

Someone hands you a reference and expects it to end the argument. A public dataset, a benchmark score, a pilot at a company in your sector. It looks like evidence, it is cited with confidence, and it is usually offered at the moment a decision is about to cost money.

The question is never whether the reference is good. Published datasets and benchmarks are mostly careful work by people who documented exactly what they built. The question is whether that particular reference tests the particular decision in front of you. Most of the time it tests a neighbouring decision, and the gap between the two is where budget disappears.

Why this matters: an evaluation built on the wrong reference produces a number that is correct and useless. It will pass review, it will go in the deck, and it will not predict what happens when the system meets your data, your conditions and your users. Worse, it is hard to argue with afterwards, because nobody disputes the arithmetic. They dispute the fit, eighteen months late.

What follows is the five-test pass we run before accepting any reference as decision-grade, and the four verdicts it ends in: ACCEPT, QUALIFY, SUBSTITUTE, or REJECT.

The reference is not the evidence. The fit is.

Write down the decision first, in one sentence, before you look at what you were given. Something like: can this model read our incoming supplier documents accurately enough that a person only checks the exceptions? Or: will this bearing monitoring approach warn us early enough on our own machines to change a maintenance window?

Now hold the reference up against that sentence. A reference earns the word evidence only if a poor result on it would actually change your mind. If a bad score would leave you saying "that was a different setting anyway", the reference was decoration from the start. This is the same discipline as declaring what an unclear outcome means before you run the test, which our note on why not evaluable is itself a result works through in a research setting.

Test 1: Can you name exactly what you were shown?

Ask for the identity of the reference, not its nickname. "The bearing dataset" and "the standard NER benchmark" are not names. A name is a persistent identifier plus a version, and the good sources give you one without being asked.

Two public examples show what that looks like. The Zenodo record run-to-failure data set of ball bearings subjected to time-varying load and speed conditions carries a digital object identifier, 10.5281/zenodo.10868257, and a deposit year of 2024. The Reuters corpora distributed by the United States National Institute of Standards and Technology are specified to a level most vendors never reach: the English Volume 1 collection is dated 1996-08-20 to 1997-08-19, with a release date of 2000-11-03, format version 1 and correction level 0.

Correction level is the detail worth noticing. A corpus can be re-released with fixes, which means two people can both say "we used Volume 1" and have used different bytes. If your supplier cannot tell you the version and the correction state of what they measured, you do not have a reproducible reference, you have an anecdote with a number attached.

Test 2: Was it collected under the conditions you operate in?

This is where most references fail, and they fail quietly, because the topic matches.

Consider the bearing example. A run-to-failure set recorded under time-varying load and speed is not interchangeable with an older fault corpus recorded at constant speed, even when both are bearings from the same laboratory family. The whole difficulty of the varying-condition case is that the signal shifts with the operating point, which is why the accompanying conference work, "Remaining Useful Lifetime Estimation of Bearings Operating under Time-Varying Conditions", treats it as its own problem rather than a harder version of the constant-speed one. A method validated on the constant-speed corpus has not been shown to work on your variable-duty equipment.

The language case is sharper still. A named-entity benchmark from the 2003 shared task published at the Conference on Computational Natural Language Learning, "Introduction to the CoNLL-2003 Shared Task: Language-Independent Named Entity Recognition", measures finding people, places and organisations in news wire text from the 1990s. It does not tell you how a system reads Dutch legal correspondence containing personal data, and a strong score on it is not a privacy control.

Note the trap in the near miss. The multilingual Reuters Volume 2 collection does contain Dutch, over 487,000 stories across thirteen languages, so a supplier can honestly say "Dutch is covered". Read one line further: those stories were written by local reporters and are explicitly not parallel translations of each other, and they are still news. Dutch news from the 1990s is not your contract archive. Domain, register, era and document structure all have to survive the comparison, not just the language label.

Test 3: May you actually use it for this purpose?

Rights are a separate question from quality, and they are decided by whoever holds them, not by how easy the download is.

The two public examples sit at opposite ends. The Zenodo bearing deposit is published under a Creative Commons Attribution 4.0 licence, which is permissive and asks for credit. The Reuters corpora are not a download at all: the distributing institute requires a request and signed agreements before release. Same field, same apparent availability, completely different obligations.

Three rules keep this clean. Read the licence on the record itself rather than a summary in a slide. Establish who signs, because an agreement naming a university research group does not extend to your commercial deployment. And never let anyone, including an adviser, tell you that a dataset is cleared for your commercial use as a reassurance; that is a conclusion for whoever holds the rights and, where it matters, your own counsel. If the rights question is unresolved, the reference is not usable yet, however good it is.

Test 4: Who decided what "correct" means?

Every score compares a system output against something treated as truth. Ask where that truth came from, because the answer sets the ceiling on what the number can mean.

The strongest form is an observed outcome. Run-to-failure data is valuable precisely because the component actually failed: the end of life is recorded, not estimated by a reviewer. The next form is independent annotation, where people other than the system builders labelled the data under a published scheme, which is what a shared task provides. The weakest form, and the most common one in vendor material, is truth produced by the same party that produced the system, or by another model.

When the builder both answers and marks the paper, the number tells you about internal consistency, not accuracy. That is not fraud, it is just a different measurement, and it should be labelled as one. Our piece on the distance between benchmark results and delivered value covers what usually survives that translation.

Test 5: Does the reported metric move the decision you have to make?

A reference can be correctly identified, well matched, properly licensed, independently labelled, and still report the wrong quantity.

Translate the metric into your operating consequence before you accept it. An entity-level score says nothing directly about how many documents reach a person for review, which is the number that decides whether the workflow saves anyone time. A remaining-life estimate is only useful if its error is small relative to the notice you need to move a maintenance window; being right on average while wrong by a week is not actionable if your window is three days. Ask what error rate you can absorb, and in which direction, then check whether the reference reports that at all. Often it does not, and the honest conclusion is that a further measurement is needed.

Reading the verdict: ACCEPT, QUALIFY, SUBSTITUTE, REJECT

One reference, one verdict, written down where the decision is recorded.

ACCEPT when all five tests pass: named and versioned, collected under conditions close enough to yours, usable under rights you actually hold, independently grounded, and reporting a quantity that changes your decision. Proceed, and cite it by identifier.

QUALIFY when the reference is sound but narrower than the claim it is being used to support. Keep it, and write the limit next to it: this evidence covers constant-speed operation, or news-domain text, and the question of our own conditions remains open. Most good references end here, and that is a healthy outcome rather than a failure.

SUBSTITUTE when the question is right and the reference is wrong. The fix is not a better model, it is a fitting reference: a public source collected under your conditions, or a small, purpose-built evaluation set from your own data with your own accepted truth. Budget for building one; it is usually cheaper than the wrong build it prevents.

REJECT when the reference cannot inform this decision at all, when it is unnamed or unversioned, when the truth was produced by the party being evaluated, or when nobody can state the rights position. Rejecting a reference is not rejecting the project. It means the project does not yet have the evidence to justify the next commitment, which is a finding worth having before the invoice.

What to ask for in writing

Send five requests, and treat a missing answer as an answer.

1. The persistent identifier and version of every dataset or benchmark behind the claim.
2. The collection conditions: when, where, in which language and register, under what operating regime.
3. The licence or agreement, and who the signing party is.
4. How the reference truth was established, and by whom, independently of the system.
5. The metric definition, and the operating consequence it maps to for us.

Suppliers who work this way answer in a day and often volunteer the limits themselves. That response is itself a strong signal, usually a better one than the score. The same before-you-commit posture applies to the workflow itself, which our companion piece on the seven questions that decide whether to automate at all sets out.

Frequently Asked Questions

Does this mean public benchmarks are not useful?

They are very useful, for the decisions they were built to inform. A public benchmark is a well-documented measurement of a specific setting, and its documentation is usually the most honest part of the whole conversation. The failure is not in the benchmark, it is in borrowing its authority for a different setting.

We have no public reference that matches our conditions. What then?

That is a SUBSTITUTE verdict, and it is common outside consumer domains. Build a small evaluation set from your own data with an accepted definition of correct, sized to the decision rather than to research convention. A few hundred well-chosen, honestly labelled items usually decides a workflow question that no public benchmark can.

A supplier showed us a deployment at a company like ours. Is that a reference?

It can be, and the same five tests apply. Name it precisely, establish which conditions matched and which did not, confirm what you are permitted to be told and repeat, ask who measured the result, and check that the reported outcome is the quantity you care about. An unnamed result at an unnamed company fails Test 1 before you reach the interesting questions.

Who should own this pass internally?

Whoever will be accountable for the outcome, supported by someone who can read a data record. In a company of twenty to fifty people that is usually the CTO or engineering leader together with the COO or operations leader who owns the process, with the founder involved only where the rights position is unresolved. It is deliberately not delegated to the party proposing the build.

Related reading

• Not evaluable is a result, on declaring in advance what an unclear outcome will mean.
• Delivering value against benchmark results, on what survives the move from score to operation.
• Seven questions before you automate a workflow, the decision that comes before this one.

Have a reference you are being asked to trust?

Send the reference, the decision it is supposed to settle, and the conditions you actually operate in. We will tell you whether it should be ACCEPT, QUALIFY, SUBSTITUTE, or REJECT before you build an evaluation on top of it.

Write to info@firstaimovers.com or read how we work on AI consulting.

TL;DR: Seven questions that decide whether one workflow should be automated now, repaired first, deferred, or left alone before you commit budget to an AI build.

The useful first deliverable of an automation project is not a list of AI ideas. It is enough evidence to decide whether one specific workflow should be automated now, repaired first, deferred, or deliberately left alone. Most teams skip that decision. They pick the workflow that annoys them most, ask a vendor or an internal engineer for a demo, and discover the real constraints after the budget is committed.

Why this matters: a workflow that is not decision-ready cannot be automated well, only faster. If the process produces noise, automation produces noise at scale. If the process depends on a fact nobody can access lawfully, the agent will guess. If nobody can define what "good enough" means, the build never leaves pilot. The seven questions below are the diagnostic we use before any implementation conversation. Each one ends in a fact you can write down, and the last one ends in exactly one verdict: BUILD, REPAIR_FIRST, DEFER, or STOP.

They are written for the people who own the budget and the risk: the CTO or technical leader who will be asked to build it, the COO or Head of Operations who lives with the workflow today, and the founder of a 20-person company who is being told that "AI automation" is the obvious next step.

1. What decision or outcome does the workflow exist to produce?

Start with the output, not the steps. Every workflow exists to produce something a person acts on: an approved invoice, a quote a customer can accept, a ticket routed to the right engineer, a compliance record an auditor will trust. Write that outcome down in one sentence, and name who consumes it.

If the answer is vague, stop here for a moment. A workflow whose output is not decision-useful, one that generates reports nobody reads or updates a spreadsheet nobody trusts, is a candidate for removal, not for automation. Automating the steps only accelerates the noise. Some of the best outcomes of this question are workflows that get deleted.

If the output is clearly useful, you now have the acceptance target that every later question refers back to.

2. Where is time or failure actually concentrated?

Capture a current baseline in a directly observable unit before anyone estimates savings: manual minutes per item, rework count, wait time between handoffs, exception rate, or how often the same item is touched twice. Measure it for a week or two, or pull it from the systems you already have. Do not invent the number, and do not let a vendor invent it for you.

Two things happen when you do this. First, you often find that the expensive part is not the part people complain about. The complaint is usually about tedium; the cost is usually in exceptions, waiting, and rework. Second, you get the only baseline that can later tell you whether the automation worked. Without it, every later claim of improvement is a story.

If you cannot measure the workflow at all, that is a finding in itself. It usually points to REPAIR_FIRST, because a process nobody can observe is not one you can safely hand to software.

3. What is the strongest non-AI alternative?

For every candidate workflow, name the best alternative that involves no model at all. The honest list is usually short and often better than a bespoke agent: remove the step entirely, change a configuration in a system you already pay for, connect two systems with a plain integration, write a deterministic rule, or buy an existing product that already does this well.

The reason to be strict here is cost of ownership, not fashion. A rule-based check or a native integration is cheaper to test, cheaper to explain to an auditor, and cheaper to keep running when the underlying system changes. An AI component earns its place only where the input is genuinely unstructured or the judgement is genuinely fuzzy, and even then it should be the smallest possible part of the pipeline.

Our guide to the four-level automation maturity ladder covers where deterministic automation stops and where model-based steps start to make sense.

4. Which systems and data must be touched?

Name the integration boundary explicitly: every system the workflow reads from, every system it writes to, and every fact it needs that lives in someone's head, inbox, or personal spreadsheet. Then classify each input. Is it available through a supported interface? Is it private, regulated, or subject to a contract? Is it operationally fragile, meaning it changes shape without notice?

This question is where many "quick wins" quietly become platform projects. A workflow that needs three facts from a system with no supported interface, one fact that is personal data with no lawful basis for the new use, and one fact that only exists in a manager's memory is not ready. Naming the boundary also tells you who has to be in the room: the data owner, the system owner, and whoever answers for privacy.

If the boundary is clean, note it and move on. If it is not, the verdict is almost always REPAIR_FIRST or DEFER, and you now know exactly which dependency to fix.

5. What can fail, and who notices?

Define the failure modes before building around a demo. For each one, decide three things: whether a human is in the loop before the effect lands, how the effect is rolled back, and what audit trail exists afterwards. Then write down the one thing that must never fail silently. In a quoting workflow that is a wrong price reaching a customer; in a payroll workflow it is a wrong amount reaching a bank.

Silent failure is the specific risk that separates automation from delegation. A person who is unsure asks; software that is unsure proceeds. If the workflow would fall under the EU AI Act's high-risk categories, human oversight is a design requirement under Article 14 of the regulation, not a preference. Even outside those categories, the operational question is the same: who sees the failure, how quickly, and with what means to undo it.

The public account of why pure automation failed at a large fintech and had to be partially reversed is a useful reminder that the failure that matters is often the one nobody was watching for.

6. What does "good enough" mean before production?

Specify the evaluation and the acceptance threshold before anyone builds. That means a reference set of real past items with known correct outcomes, an agreed measure (accuracy on the reference, exception rate, time to resolution), and a threshold below which the automation stays out of production. The reference should be assembled by the people who own the workflow, not by the people who want to build the automation.

This is the question a demo is designed to skip. A demo shows the happy path on chosen examples; a reference tests the decision on the examples that actually arrive. If you cannot assemble a reference from your own history, you have learned that the workflow is not yet observable enough, which is again REPAIR_FIRST territory.

Write the threshold down with the baseline from question 2. Together they are the whole contract: here is where we are, here is the number at which we switch this on, here is the number at which we switch it off.

7. What is the decision today?

Pick exactly one verdict and record the evidence behind it. Do not leave the workshop with a "maybe".

• BUILD. The outcome is decision-useful, the baseline is measured, no non-AI alternative dominates, the integration boundary is clean, failure modes have owners and rollbacks, and a reference with a threshold exists. Proceed to the smallest implementation that can be tested against that reference.
• REPAIR_FIRST. The workflow is worth automating but is not ready: the process is unobservable, the data boundary is broken, or the output is inconsistent. Fix the named dependency first. This is the most common honest verdict.
• DEFER. Automation is plausible but the expected value does not beat the current cost, or a dependency is changing (a system migration, a regulatory clarification). Set the condition that reopens the decision and a date to re-check it.
• STOP. The workflow should not be automated: the output is not useful, a non-AI alternative removes the need, or the failure modes cannot be made acceptable. Retire the idea explicitly so it does not come back as someone else's project.

A single-page record with the seven answers and the verdict is the deliverable. It is more valuable than a roadmap of twenty automation ideas, because it is the one document that lets the technical leader, the operations leader, and the budget owner say the same thing about the same workflow.

How this fits with a wider AI plan

This diagnostic is deliberately narrow: one workflow, one verdict. If you are earlier in the process and do not yet know which workflows to examine, our map-first method for planning an AI project is the step before this one. Run the map, pick the one workflow that matters most, then run the seven questions on it before anyone writes code.

Teams that do this in order tend to find that their first automation is smaller and more boring than they expected, and that it ships.

Get a decision on one workflow

Have one workflow you are unsure is worth automating? Send the workflow, the systems it touches, and the current manual pain. We will tell you whether the next step should be BUILD, REPAIR_FIRST, DEFER, or STOP before you commit to an implementation. Write to info@firstaimovers.com, or read how we work with European SME leaders on AI consulting.

Frequently Asked Questions

Q: Can we run the seven questions ourselves?

Yes. The questions are designed to be answered by the people who own the workflow, and the deliverable is a one-page record. Outside help is useful when the team cannot agree on the baseline, cannot access the systems involved, or wants an independent view on the non-AI alternatives.

Q: What if the answer to most workflows is REPAIR_FIRST?

That is the normal result in a growing company, and it is good news: it means you have found the specific process and data problems that would otherwise have surfaced halfway through an implementation. Fix the one that unblocks the most valuable workflow first.

Q: How long should the diagnostic take?

For one workflow with cooperative owners, a few working days: one to gather the baseline and the system list, one for the workshop, and time to write the record. If it takes much longer, the workflow is probably not observable enough yet, which is itself a finding.

Q: Does a STOP verdict mean we were wrong to consider automation?

No. STOP is a legitimate outcome and often a cheap one. The cost of a STOP verdict is a few days of attention; the cost of discovering the same thing after a build is months.

TL;DR: A T-cell signal reached PP4 near 0.992 in one dataset. An independent public blood T-cell cohort did not support it.

PP4 ≈ 0.992 looked exciting. An independent public blood T-cell cohort did not support it, and secondary checks did not change that. This case study, from our prospectively frozen analysis of public data, shows what it takes to stop one striking number from quietly becoming a causal story.

It is part of our technical report, Falsification-First AI for Biological Target Assessment. Technical report; not peer reviewed. The citable version is our open-access preprint [5]. Nothing here is a clinical or therapeutic claim.

The setup

While testing a different ulcerative colitis (UC) hypothesis, our workflow surfaced an unexpected signal for the gene TTPAL at the UC 20q13 locus.

Our result (discovery). In the discovery resource, the signal reached an apparent colocalization posterior of up to about PP4 = 0.992 in three gut-resident T-cell groups, out of 66 designated groups. Those three groups overlap within one donor lineage, so they are not three independent replications.

Source fact. PP4 is the posterior probability, under a Bayesian colocalization test, that two association signals (here, the disease association and the gene-expression association) share a single causal variant [1]. It is a model score under that test's assumptions, not the probability that TTPAL causes disease [5]. A value near 0.992 is the kind of number that ends up on a slide.

The safeguard

We treated that number as nomination evidence only, not as a finding. Before reading any independent outcome, we:

• sealed the discovery dataset, so it could not be reused to "confirm" itself;
• prospectively defined the independent confirmation: which public cohorts were admissible, in what order, at which locus and window, and what result would count as replication.

What happened

Our result (independent test).

• Primary independent cohort. OneK1K is a peripheral-blood single-cell eQTL resource [2], with up to approximately 954 donors in the eligible cell classes used by our frozen study. TTPAL had no usable supporting signal at the frozen locus and window. The maximum PP4 across the evaluated T-cell classes was approximately 0.031.
• Secondary independent resources. CEDAR [3] did not support the nominated TTPAL effect. Kasela 2017 [4] had no usable confirming signal.
• No alternative winner. No other local gene clearly won the independent confirmation analysis.

Decision

SINGLE_DATASET_ONLY. The exciting discovery signal remained single-dataset-only.

The caveat that travels with this result

The discovery cells were gut-resident T cells. The admissible independent public cohorts were peripheral blood. That difference matters:

• This result does not prove that a tissue-resident TTPAL effect is false.
• It does not say the discovery result was wrong.
• It shows only that the discovery signal did not independently reproduce on the public data available for this test.

Keeping that caveat next to the result is part of the method. Dropping it would turn an honest "not replicated here" into a misleading "disproven".

Why it matters

The purpose of scientific diligence is not to make an exciting number disappear. It is to prevent one exciting number from silently becoming a causal story. An impressive posterior in one dataset is not replication, and the time to find that out is before the next expensive step, not after it.

For the general version of this discipline, see what makes an AI system trustworthy, as NIST describes it. The companion case study, Not Evaluable Is a Result, shows the other outcome that matters: a causal bridge that public data simply cannot decide.

Try it on your own target

We have packaged this method as the Biodius Target Challenge: a fixed-scope, five-business-day adversarial review of one target or mechanism, ending in a decision memo. Send us one target + indication + rationale. We will tell you whether it deserves the next expensive step. You can reach us at info@firstaimovers.com, or learn more about First AI Movers.

References

1. Giambartolomei et al. Bayesian test for colocalisation between pairs of genetic association studies using summary statistics. PLoS Genetics 10(5): e1004383 (2014). https://doi.org/10.1371/journal.pgen.1004383
2. Yazar et al. Single-cell eQTL mapping identifies cell type-specific genetic control of autoimmune disease. Science 376(6589): eabf3041 (2022). https://doi.org/10.1126/science.abf3041
3. Momozawa et al. IBD risk loci are enriched in multigenic regulatory modules encompassing putative causative genes. Nature Communications 9: 2427 (2018). https://doi.org/10.1038/s41467-018-04365-8
4. Kasela et al. Pathogenic implications for autoimmune mechanisms derived by comparative eQTL analysis of CD4+ versus CD8+ T cells. PLoS Genetics 13(3): e1006643 (2017). https://doi.org/10.1371/journal.pgen.1006643
5. Costa, H. (2026). Falsification-First AI for Biological Target Assessment: Lessons from Four Prospectively Frozen Experiments [Preprint]. Zenodo. https://doi.org/10.5281/zenodo.23057911

TL;DR: Four prospective experiments taught us that scientific AI is most useful when it attacks a hypothesis. So we built a fixed-scope target diligence review.

Three of our four prospective experiments did not end the way we hoped, and that turned out to be the most useful thing they produced.

We spent the past months testing AI-assisted biological target assessment on ourselves, prospectively, using public data in pulmonary fibrosis and inflammatory bowel disease. We fixed our analysis rules before reading decisive outcomes and kept every negative result. The write-up is our technical report, Falsification-First AI for Biological Target Assessment (technical report; not peer reviewed), and the citable version is our open-access preprint, doi.org/10.5281/zenodo.23057911. This article explains what we learned and what we are doing about it.

What the experiments taught us

Rigor has to earn its complexity. A heavier scientific-agent architecture did not demonstrate more useful biological coverage than a strong agentic research workflow. It had useful safeguards, but more machinery did not mean more useful biology.

A small trust layer held up in one transfer. When we cut the safeguards down to a lean layer, it preserved the useful output, added decision-relevant annotations about provenance, independence and contradictions, and transferred to a new disease area without being tuned to the old one. One transfer does not show that smaller systems are better.

Missing data is a result. One candidate that survived initial adversarial review was later kept at NOT_EVALUABLE, because the causal bridge it depended on could not be measured from available lawful public data. It was not disproven. It just had not earned the next step. The full case.

One impressive number is not replication. We independently challenged an apparent PP4 ≈ 0.992 T-cell signal and did not reproduce it in independent public blood T-cell resources. The discovery cells were gut-resident and the independent cohorts were blood, so this does not prove the original effect false; it shows the signal was single-dataset-only. The full case.

The gap we think this fills

AI is making it cheap to assemble a convincing biological story. It is not making it cheaper to find out whether that story deserves money. If anything, the gap is widening: more plausible hypotheses, written more fluently, arriving faster than anyone can check them.

The people who feel this most are the ones about to commit to an expensive next step: a biotech team choosing which mechanism to take forward, or an investor deciding whether the biology behind an asset holds up. They do not need another literature summary. They need someone to try to break the case, count shared cohorts once, keep the contradicting results in view, and say plainly which causal claim has actually been earned.

What we are offering

We have packaged the method as the Biodius Target Challenge. You send one target, pathway or mechanism, one indication, your current rationale and the decision you are facing. Over five business days we run a falsification-first review: provenance, human-genetics and causal-gene evidence where relevant, cohort independence, contradictions and failed programs, a causal-chain audit, a novelty attack and independent synthetic challenges adjudicated against primary sources. You get a concise decision memo, ADVANCE, REWORK, STOP or NOT_EVALUABLE, plus the cheapest evidence that would change it.

The founding pilot is EUR 4,950 excl. VAT, with 3 founding design-partner slots, fixed scope, subject to a decision-sufficient brief and final contracting route. Details are on the Biodius Target Challenge page.

What it is not

Biodius is experimental scientific diligence tooling. It does not discover drug targets, predict clinical success, provide clinical advice, validate safety or efficacy, perform wet-lab work, or replace qualified scientific, legal, patent or regulatory judgment. It has not been externally validated.

An honest hypothesis

Our current commercial hypothesis is that this workflow is useful as scientific diligence before a costly downstream decision. We could be wrong about that, and the founding pilots exist to find out. We would rather test the hypothesis on real target decisions than keep generating new biology of our own.

If you have a target or mechanism you would value having independently stress-tested, send us one target + indication + rationale at info@firstaimovers.com. We will tell you whether it deserves the next expensive step. You can also read more about First AI Movers.

TL;DR: A fixed-scope, five-business-day adversarial review of one biological target or mechanism, ending in an ADVANCE, REWORK, STOP or NOT_EVALUABLE memo.

Biodius is a falsification-first scientific diligence service for biotech teams and investors. We stress-test the evidence behind a biological target or mechanism, collapse non-independent studies, surface contradictions and failed programmes, challenge causal-gene and novelty claims, and identify the cheapest evidence that would actually change the decision.

Send us one target + indication + rationale, or ask for a 20-minute fit call at the same address.

The problem

The expensive mistakes in target work rarely come from a lack of evidence. They come from evidence that looks stronger than it is: multiple papers that share one cohort, a causal chain with one link nobody measured, a striking statistic from a single dataset, a negative result nobody went looking for. By the time those show up, the next expensive step has usually been funded.

Why ordinary AI research is not enough

AI research tools make it fast and cheap to assemble a convincing biological story. That is exactly the risk. Throughput is not truth: a system rewarded for producing plausible hypotheses will produce more of them, and a well-written summary can turn "plausible and not yet disproven" into confidence. What a target decision needs is the opposite job: an attempt to break the story before money is committed to it.

Biodius Target Challenge

The Target Challenge is a fixed-scope adversarial review of one target, pathway or mechanism in one indication. We try to kill it. What survives, what does not, and what cannot be decided from the evidence are all reported, and the review ends in a decision memo, not a summary.

What you send

• one target / pathway / mechanism;
• one indication;
• your current rationale;
• the next decision you are considering.

What you receive

• source/provenance map;
• genetics/causal-gene check where relevant;
• cohort/study independence map;
• contradiction, null and failed-programme register;
• causal-chain audit;
• novelty/prior-art attack;
• independent synthetic expert challenges where appropriate;
• adjudicated source check;
• cheapest discriminating next evidence;
• concise decision memo: ADVANCE | REWORK | STOP | NOT_EVALUABLE.

Two cases from our own tests

We tested this method on ourselves first, prospectively, on public data. Two outcomes show what it is for.

A plausible mechanism that public data could not decide

An AI-generated ulcerative colitis hypothesis survived an initial evidence bar and two adversarial AI reviewers. A frozen human-genetics adjudication then found that its decisive causal link could not be evaluated from lawful public data. The hypothesis was not promoted, and it was not disproven: it was NOT_EVALUABLE. Read the case study.

A striking signal that did not replicate

An unexpected T-cell signal reached PP4 up to about 0.992 in three gut-resident T-cell groups (of 66 designated groups) in a discovery dataset. We sealed that dataset and defined an independent test in advance. The signal did not reproduce in independent public blood T-cell cohorts. Because those cohorts were blood and the discovery cells were gut-resident, this does not prove a tissue-resident effect is false; it shows the signal was single-dataset-only. Read the case study.

How the method works

We prospectively freeze analysis rules before reading decisive outcomes. We deliberately preserve negative, contradictory and not-evaluable results. We distinguish publications from independent cohorts and collapse shared lineages. Independent AI reviewers are tasked with falsifying the case, and their challenges are adjudicated against primary sources. The full method and all four of our prospective experiments are in the technical report, Falsification-First AI for Biological Target Assessment (technical report; not peer reviewed). The citable version is our open-access preprint on Zenodo: doi.org/10.5281/zenodo.23057911.

Who it is for

• Biotech teams about to commit to a costly next step on a target or mechanism.
• Investors who want an independent, adversarial read of the biology behind an asset before a funding decision.

What we do not claim

Biodius does not provide clinical advice, validate safety or efficacy, perform wet-lab work, or replace legal/patent/regulatory review.

It is experimental scientific diligence tooling. It does not discover drug targets or predict clinical success, it has not been externally validated, and it does not substitute for qualified scientific judgment. Our current commercial hypothesis is that this workflow is useful as scientific diligence before a costly downstream decision. More answers are in the Target Challenge FAQ.

Founding pilot

• 5 business days
• EUR 4,950 excl. VAT
• 3 founding design-partner slots
• fixed scope, subject to a decision-sufficient brief and final contracting route

Start with one target

Send us one target + indication + rationale. We will tell you whether it deserves the next expensive step.

Send us one target + indication + rationale: tell us the target, pathway or mechanism; the indication; your current rationale; and the next decision you are considering.

Prefer to talk first? Ask for a 20-minute fit call at info@firstaimovers.com. Learn more about First AI Movers.

TL;DR: What the Biodius Target Challenge reviews, what you send, what you get back, what it costs, and what it does not claim to do.

The Biodius Target Challenge is a fixed-scope scientific diligence review of one biological target or mechanism. These are the questions teams usually need answered before they send one. For the offer itself, see the Biodius Target Challenge.

What is the Biodius Target Challenge?

It is an adversarial evidence review of one target, pathway or mechanism in one indication. Instead of building the strongest case for your target, we try to kill it: we collapse non-independent studies, surface contradictions and failed programs, challenge causal-gene and novelty claims, and identify the cheapest evidence that would actually change your decision.

Biodius is experimental scientific diligence and falsification tooling. It is not a clinical system, a therapeutic recommendation engine or a validated drug-discovery platform.

Who is it for?

Biotech teams and investors who are about to commit to an expensive next step on a biological target or mechanism, and who want the evidence stress-tested before they do. It is most useful when an interesting biological story is about to become a costly decision.

What do I need to send?

• one target, pathway or mechanism;
• one indication;
• your current rationale;
• the next decision you are considering.

The review is fixed-scope, so a clear rationale and a clear decision matter more than volume.

What do I get back?

• a source and provenance map;
• a genetics and causal-gene check where relevant;
• a cohort and study independence map;
• a contradiction, null and failed-program register;
• a causal-chain audit;
• a novelty and prior-art attack;
• independent synthetic expert challenges where appropriate;
• an adjudicated source check;
• the cheapest discriminating next evidence;
• a concise decision memo: ADVANCE | REWORK | STOP | NOT_EVALUABLE.

How long does it take, and what does it cost?

The founding pilot is 5 business days, at EUR 4,950 excl. VAT. There are 3 founding design-partner slots. The scope is fixed, subject to a decision-sufficient brief and the final contracting route.

How is this different from a literature review?

A literature review summarizes what has been published. A falsification-first review asks what the published evidence can actually support. It counts shared cohorts once, keeps negative and contradictory results in view, tests each link in the causal chain separately, and ends with a decision rather than a summary. In our own prospective tests, that difference was the whole point: one mechanism that survived initial AI review turned out to be not evaluable from public human data, and one striking signal did not replicate.

What does NOT_EVALUABLE mean?

It means the available lawful public data cannot decide the question. It is a result, not a failure to finish. We report it as such rather than rounding it up to "promising" or down to "false", and we tell you what evidence would decide it.

Does Biodius discover or validate drug targets?

No. Biodius does not discover drug targets, predict clinical success or validate a target. It tests whether the evidence behind a target you already have has earned the next expensive step.

Does it give clinical advice or validate safety?

No. Biodius does not provide clinical advice, validate safety or efficacy, perform wet-lab work, or replace legal, patent or regulatory review. It does not substitute for qualified scientific judgment.

How is AI used, and why should I trust the output?

AI research agents do the broad evidence gathering, and independent AI reviewers are tasked with falsifying the case rather than improving it. Their challenges are then adjudicated against primary sources, and the analysis rules are fixed before the decisive evidence is read. We do not claim the AI is unbiased; the workflow is designed so that a weak claim has to survive more than one attempt to break it.

What evidence is there that the method is useful?

Our own four prospective experiments on public data, written up in our technical report and in an open-access preprint you can cite: Costa, H. (2026), Falsification-First AI for Biological Target Assessment: Lessons from Four Prospectively Frozen Experiments, Zenodo, doi.org/10.5281/zenodo.23057911. Neither is peer reviewed, and the method has not been externally validated. Our current commercial hypothesis is that this workflow is useful as scientific diligence before a costly downstream decision; the founding pilots exist to test that.

What if my rationale is confidential?

Start with a 20-minute fit call and share only what you are comfortable sharing at that stage. We will tell you whether the question fits the format before you send anything detailed.

How do I start?

Send us one target + indication + rationale. We will tell you whether it deserves the next expensive step. Email info@firstaimovers.com, or ask for a 20-minute fit call at the same address. You can also read more about First AI Movers.

TL;DR: A plausible mechanism survived AI review. Public human genetics still could not decide the causal bridge, so the hypothesis was not promoted.

A plausible mechanism survived AI review. Public human genetics still could not decide the causal bridge. This case study, from our prospectively frozen analysis of public data, shows why "not yet disproven" is a different thing from "ready for the next expensive step".

It is part of our technical report, Falsification-First AI for Biological Target Assessment. Technical report; not peer reviewed. The citable version is our open-access preprint [3]. Nothing here is a clinical or therapeutic claim.

The setup

Hypothesis. An AI research workflow generated a biologically coherent ulcerative colitis (UC) hypothesis. It linked a genetic signal in the HNF4A region, biology associated with SLC26A3, and a penetrable-mucus phenotype.

Source facts. The pieces were individually reasonable. The HNF4A region is an established UC susceptibility locus from genome-wide association analysis [1], and a penetrable inner colonic mucus layer has been described in patients with UC [2].

The hypothesis survived an initial frozen evidence bar and two independent synthetic falsifiers: AI reviewers tasked with breaking it rather than improving it. At that point, a conventional research summary would call it a lead.

The challenge

We did not accept "survived review" as confirmation. We froze a genotype-resolved causal adjudication before inspecting the decisive outcomes. The rules, the admissible public data sources and the conditions for each possible verdict were fixed in advance, so the result could not quietly shape the method.

The question the adjudication had to answer was specific: does public human-genetic data support each link in the chain, from the genetic signal, to the gene, to the downstream biology?

What happened

Our result. Link by link:

• The gene assignment weakened. Cell-type-resolved evidence did not support assigning the signal to HNF4A strongly enough under the frozen tiering.
• The decisive bridge was not evaluable. The HNF4A→SLC26A3 mediation step could not be evaluated from the lawful public aggregate data available, because no admitted public trans-eQTL or equivalent mediation surface could decide it.
• Locus support softened. Support at the SLC26A3 locus weakened under cell-state adjustment and turned out to depend on the dataset.
• Tissue specificity stayed open. Whether the effect is specific to the colon rather than the ileum remained not evaluable.

Decision

The hypothesis was not promoted. The decisive causal bridge could not be established from public data.

To be precise about what that means: the hypothesis was not disproven. Its outcome is NOT_EVALUABLE: the available lawful public data cannot decide the step the whole mechanism depends on. Failure to falsify is not confirmation, and missing data is a result.

Why it matters

A conventional research summary can easily turn "plausible and not yet disproven" into confidence. Two reviewers tried and failed to break it; the pieces each have literature behind them; the story reads well. The diligence question is different: what causal statement has actually earned the next expensive step?

Here, the honest answer was "not this one, not yet". That is useful to know before committing budget, and it points at the exact evidence that would change the answer: a way to measure the mediation link directly.

The same pattern shows up well beyond biology. Our guide on why agentic AI autonomy is not ready to run unchecked makes the business version of the argument. A companion case study, 0.992 Was Not Replication, shows the other common trap: one impressive number from one dataset.

Try it on your own target

We have packaged this method as the Biodius Target Challenge: a fixed-scope, five-business-day adversarial review of one target or mechanism, ending in a decision memo. Send us one target + indication + rationale. We will tell you whether it deserves the next expensive step. You can reach us at info@firstaimovers.com, or learn more about First AI Movers.

References

1. UK IBD Genetics Consortium. Genome-wide association study of ulcerative colitis identifies three new susceptibility loci, including the HNF4A region. Nature Genetics 41(12): 1330-1334 (2009). https://doi.org/10.1038/ng.483
2. Johansson et al. Bacteria penetrate the normally impenetrable inner colon mucus layer in both murine colitis models and patients with ulcerative colitis. Gut 63(2): 281-291 (2014). https://doi.org/10.1136/gutjnl-2012-303207
3. Costa, H. (2026). Falsification-First AI for Biological Target Assessment: Lessons from Four Prospectively Frozen Experiments [Preprint]. Zenodo. https://doi.org/10.5281/zenodo.23057911

TL;DR: A technical report on four prospective experiments: why scientific AI is more useful when it preserves negative evidence and stops when data runs out.

Why autonomous scientific systems should be rewarded for killing weak hypotheses, not generating more of them.

Technical report; not peer reviewed. Version 1, September 2026. This report describes our prospectively frozen analysis of public data. It makes no clinical or therapeutic claim, and it does not claim validated drug discovery. The citable version of this work is our open-access preprint (details under How to cite, below); where this report and the preprint differ, the preprint is the reference.

Abstract

Generative AI can increase the speed of biological research without increasing the reliability of the resulting scientific decisions. We developed and prospectively tested a falsification-first workflow for AI-assisted biological target assessment in which evaluation criteria, source boundaries, lineage rules and stop conditions are fixed before decisive outcomes are read. Across four sequential experiments in pulmonary fibrosis and inflammatory bowel disease, the program repeatedly produced results that were less flattering but more decision-useful than the original hypotheses. A complex scientific-agent architecture did not justify its additional complexity against a strong agentic baseline; a smaller safeguard layer transferred while preserving useful coverage; a mechanistically plausible IBD hypothesis remained not evaluable when a required human-genetic mediation link could not be tested from lawful public data; and an unexpected T-cell colocalization signal with a discovery posterior near 0.992 failed to reproduce in independent public blood T-cell cohorts. These studies do not establish a therapeutic target or clinical mechanism. They instead support a narrower proposition: scientific AI becomes more useful when it is designed to preserve negative evidence, collapse non-independent evidence, resist post-result method changes and terminate explicitly when the available data cannot support the next causal claim.

How to read this report

We keep five kinds of statement apart, and we label them where the difference matters:

• Source fact: what a cited public source reports.
• Author claim: what the authors of a source argue, which is not the same as what their data show.
• Our result: the outcome of our prospectively frozen analysis of public data.
• Inference: what we think a result implies, stated as our reading.
• Hypothesis: a claim that has not been tested yet.

The problem: AI increases scientific throughput, not truth

AI research agents are good at producing plausible biology. They can read a large literature quickly, connect a genetic signal to a pathway, and write a coherent mechanism in minutes. That speed is real. What it does not do on its own is make the resulting decision more reliable.

The failure modes are familiar to anyone who has sat in a target review. Multiple papers that look like independent support share one cohort. A causal chain has one link nobody has actually measured. A striking statistic comes from a single dataset. A method gets quietly adjusted after the first results come in. More throughput makes each of these easier to produce and harder to notice.

So the question we set out to test was not "can an AI system generate good hypotheses?" It was narrower and, we think, more useful: can an AI-assisted workflow be built so that it reliably tells you when a hypothesis has not earned the next expensive step?

Methods: how the workflow resists being fooled

Every experiment in this program shared five disciplines.

1. Prospective freezes. Evaluation criteria, source boundaries, lineage rules and stop conditions were written down and fixed before the decisive outcomes were read. We prospectively froze analysis rules before reading decisive outcomes, and a rule that changed after a result was treated as a new experiment, not a correction.
2. Lineage independence. We distinguish publications from independent cohorts and collapse shared lineages. Five papers drawing on one cohort count as one line of evidence, not five.
3. Contradiction and null preservation. We deliberately preserved negative, contradictory and not-evaluable results. A failed program, a null association or a contradicting cohort is kept in the record, not filtered out of the summary.
4. Reproducibility. Each decision rule, source boundary and terminal outcome was recorded before and after the decisive read, so the path from evidence to decision can be retraced.
5. Synthetic adversarial review. Independent AI reviewers were tasked with falsifying a candidate rather than improving it. Their challenges were then adjudicated against primary sources. A synthetic reviewer failing to break a claim was never treated as confirmation.

The method runs as one chain:

claim or target thesis → source identity and provenance → human-genetics and causal-gene evidence where applicable → study and cohort lineage collapse → contradictions, nulls and failed programs → causal-chain audit → novelty and prior-art attack → independent synthetic expert challenge → primary-source adjudication → cheapest discriminating next evidence → ADVANCE | REWORK | STOP | NOT_EVALUABLE

NOT_EVALUABLE is a first-class outcome. It means the available lawful public data cannot decide the question, and it is reported as such rather than rounded up to "promising" or down to "false".

Experiment 1: a heavier architecture against a strong agentic baseline

Our result. In a prospective benchmark in idiopathic pulmonary fibrosis (IPF), a heavier scientific-agent architecture did not demonstrate superior useful biological coverage over a strong agentic research workflow.

The heavier system was not useless. It demonstrated useful safeguards around leakage, provenance, lineage and reproducibility. But its additional machinery did not buy additional useful biology.

Inference. The result argued against retaining complexity merely because it looked rigorous. The lesson we took forward: rigor has to earn its complexity.

Experiment 2: a lean trust layer that transferred

We then reduced the safeguard stack, prospectively, to a small scientific trust layer and transfer-tested it on inflammatory bowel disease (IBD), a different disease area from the one it was designed in.

Our result.

• The lean layer preserved the agentic output rather than deleting coverage.
• It added measurable, decision-relevant annotations around provenance, independence, boundaries and contradiction handling.
• It transferred without IPF-specific, result-aware tuning.

Inference. The useful product was not a larger autonomous scientist. It was a small layer that made strong AI research harder to fool. This does not show that the layer produces better drug discovery; it shows that it adds decision-relevant scrutiny without removing useful coverage.

Case study: a plausible mechanism that public human genetics could not decide

Hypothesis. A generated hypothesis linked an HNF4A-region ulcerative colitis (UC) genetic signal, SLC26A3-associated biology and a penetrable-mucus phenotype.

Source facts. The HNF4A region is an established UC susceptibility locus from genome-wide association analysis [5]. A penetrable inner colonic mucus layer has been described in patients with UC [6].

The hypothesis survived the initial frozen candidate bar and two independent synthetic falsifiers. Many research workflows would stop there and call it a lead.

Our result. A deeper, prospectively frozen adjudication using public human genetics then found:

• cell-type-resolved evidence did not support the HNF4A assignment strongly enough under the frozen tiering;
• the HNF4A→SLC26A3 mediation link was not evaluable from lawful public aggregate data, because no admitted public trans-eQTL or equivalent mediation surface could decide it;
• the SLC26A3 locus support weakened under state adjustment and dataset dependence;
• colon-versus-ileum specificity remained not evaluable.

Decision. The hypothesis was not promoted. The decisive causal bridge could not be established from public data.

This is not a claim that the hypothesis is false. It was not disproven. Failure to falsify is not confirmation, and missing data is a result. The full case is written up in Not Evaluable Is a Result.

Case study: an exciting posterior that did not replicate

Our result (discovery). During the analysis above, an unexpected TTPAL signal at the UC 20q13 locus reached a colocalization posterior of up to about PP4 = 0.992 in three gut-resident T-cell groups in the discovery resource, out of 66 designated groups. Those three groups overlap within one donor lineage, so they are not three independent replications. PP4 is the posterior probability, under a Bayesian colocalization test, that two association signals share a single causal variant [1]. It is a model score under that test's assumptions, not the probability that TTPAL causes disease.

We treated that number as nomination evidence only. We sealed the discovery dataset and prospectively defined an independent confirmation before reading any independent outcome.

Our result (independent test).

• Primary independent cohort: OneK1K, a peripheral-blood single-cell eQTL resource [2], with up to approximately 954 donors in the eligible cell classes used by the frozen study. TTPAL had no usable supporting signal at the frozen locus and window; the maximum PP4 in the evaluated T-cell classes was approximately 0.031.
• Secondary independent resources: CEDAR [3] did not support the nominated TTPAL effect, and Kasela 2017 [4] had no usable confirming signal.
• No local gene clearly won the independent confirmation analysis.

Decision. SINGLE_DATASET_ONLY. The exciting discovery signal remained single-dataset-only.

The caveat that has to travel with this result. The discovery cells were gut-resident T cells; the admissible independent public cohorts were peripheral blood. So this result does not prove that a tissue-resident TTPAL effect is false, and it does not say the discovery result was wrong. It shows only that the discovery signal did not independently reproduce on the public data available for this test. An impressive posterior in one dataset is not replication. The full case is written up in 0.992 Was Not Replication.

What failed: the negative results in one place

We are listing these together because a report that only shows its successes would contradict its own method.

Three of the four outcomes are, by the standard of a pitch deck, disappointing. By the standard of a decision, each of them is useful: they tell you what not to fund yet, and why.

Limitations

• Four experiments, two disease areas. This is a small program. It supports a narrow claim about workflow design, not a general claim about AI in biology.
• Public data only. Every adjudication used lawful public aggregate data. Our NOT_EVALUABLE outcome reflects what public data cannot answer, not what a well-designed private study could.
• Tissue mismatch in replication. The independent T-cell cohorts were peripheral blood, while the discovery signal came from gut-resident cells.
• Synthetic reviewers are not experts. AI falsifiers were used to generate challenges, not to replace qualified scientific judgment. Every challenge was adjudicated against primary sources.
• No external validation. These are our own prospective experiments. They have not been independently replicated or peer reviewed.
• No wet-lab work. Nothing here was tested experimentally.

Implications for target assessment and scientific diligence

Inference. If AI makes it cheap to produce convincing biology, the scarce thing becomes the discipline to decide which convincing stories have actually earned money. That points to a specific job for scientific AI: not generating more hypotheses, but attacking the one you are about to fund.

In practice that means asking, before the next expensive step:

• Which pieces of evidence are genuinely independent, once shared cohorts are collapsed?
• Which link in the causal chain has actually been measured, and which has only been assumed?
• What contradicting results and failed programs exist, and were they looked for?
• Is the striking statistic replicated, or is it one dataset?
• What is the cheapest piece of evidence that would change the decision?

Our current commercial hypothesis is that this workflow is useful as scientific diligence before a costly downstream decision. We have packaged it as the Biodius Target Challenge to test that hypothesis with real target decisions. For how this fits a broader view of checking AI output before acting on it, see our guide to verifier agents and trustworthy AI output.

Reproducibility and provenance

For each experiment, the decision rules, source boundaries, stop conditions and terminal outcomes were recorded in a version-controlled record before and after the decisive read. Public inputs are identified in this report by their public publications. The internal records are retained so that each decision can be retraced. The open-access preprint adds a public evidence package: the manuscript, figure sources, a claim ledger that sets the allowed strength of each claim, a public-source register and deterministic validation scripts. Non-public source artifacts are identified there by hash rather than distributed.

For more about the team behind this work, see About First AI Movers.

No clinical or therapeutic claim

This report does not establish a therapeutic target, a clinical mechanism, or the safety or efficacy of any intervention. It does not claim validated drug discovery. Nothing in it is medical advice, and none of it substitutes for qualified scientific, clinical, legal, patent or regulatory review.

How to cite

Costa, H. (2026). Falsification-First AI for Biological Target Assessment: Lessons from Four Prospectively Frozen Experiments [Preprint]. Zenodo. https://doi.org/10.5281/zenodo.23057911

The preprint is open access under a CC BY 4.0 license. It is not peer reviewed, and its claims are bounded to the four recorded experiments.

References

1. Giambartolomei et al. Bayesian test for colocalisation between pairs of genetic association studies using summary statistics. PLoS Genetics 10(5): e1004383 (2014). https://doi.org/10.1371/journal.pgen.1004383
2. Yazar et al. Single-cell eQTL mapping identifies cell type-specific genetic control of autoimmune disease. Science 376(6589): eabf3041 (2022). https://doi.org/10.1126/science.abf3041
3. Momozawa et al. IBD risk loci are enriched in multigenic regulatory modules encompassing putative causative genes. Nature Communications 9: 2427 (2018). https://doi.org/10.1038/s41467-018-04365-8
4. Kasela et al. Pathogenic implications for autoimmune mechanisms derived by comparative eQTL analysis of CD4+ versus CD8+ T cells. PLoS Genetics 13(3): e1006643 (2017). https://doi.org/10.1371/journal.pgen.1006643
5. UK IBD Genetics Consortium. Genome-wide association study of ulcerative colitis identifies three new susceptibility loci, including the HNF4A region. Nature Genetics 41(12): 1330-1334 (2009). https://doi.org/10.1038/ng.483
6. Johansson et al. Bacteria penetrate the normally impenetrable inner colon mucus layer in both murine colitis models and patients with ulcerative colitis. Gut 63(2): 281-291 (2014). https://doi.org/10.1136/gutjnl-2012-303207

TL;DR: Visible momentum across open agent platforms in July 2026, with new releases from Dify and LangChain. What this means for European engineering teams.

July 2026 brought a wave of updates across open agent platforms that European engineering leaders cannot afford to ignore. New releases and guides from projects like Dify and LangChain's Open Agent Platform signal a maturing ecosystem where agents can be built with visual canvases, orchestrated in multi-agent systems, and deployed on self-hosted infrastructure. The evidence from public sources, including DailyAIWorld, MarkTechPost, and KDnuggets, is not an endorsement of any single tool. It is corroborating evidence of a broader trend: open agent frameworks are moving from experimental projects to practical building blocks for small and mid-sized teams.

The Rise of Visual Agent Builders

This review highlighted how a class of tools now exposes retrieval, agents, and workflows through visual canvases, web UIs, and plain-English prompts. Among them, Dify released an agent beta (https://dailyaiworld.com/blogs/dify-agent-beta-guide-2026) that allows users to construct tools, agents, and multi-agent workflows without manual coding. Dify's approach is particularly noteworthy because it argues that agent frameworks often exclude non-programmers, and it reports strong open-source results on the GAIA benchmark.

Another platform, the LangChain Open Agent Platform (OAP) (https://github.com/langchain-ai/open-agent-platform), provides a no-code, web-based interface for building and managing LangGraph agents. Its core features include first-class RAG through LangConnect, tool access via MCP servers, and multi-agent orchestration through an Agent Supervisor. Users assemble chatbots, RAG pipelines, and multi-agent systems on a canvas, with integrations for observability tools like LangSmith and LangFuse. AutoAgent, mentioned in the KDnuggets review (https://www.kdnuggets.com/10-agentic-ai-frameworks-you-should-know-in-2026), also functions as an open alternative to hosted Deep Research products, further illustrating the shift toward stand-alone, self-hosted agent builders.

These visual platforms are not merely toys. They address a real pain point for small and mid-sized European companies: the need to automate complex workflows without a large AI engineering team. By self-hosting these platforms, teams retain data control within their own environment, a critical requirement under European data regulations. However, licenses differ. While AutoAgent, AnythingLLM, Open Agent Platform, and Langflow use permissive MIT licenses, others like n8n employ a fair-code Sustainable Use License with commercial restrictions. For European SMBs evaluating long-term viability, understanding these license terms is essential before integrating any platform into production pipelines.

Code-First Frameworks That Reward Deep Control

While no-code platforms lower the barrier, code-first frameworks remain the choice for teams that need fine-grained control over agent behavior, durability, and state management. KDnuggets' July 2026 roundup (https://www.kdnuggets.com/10-agentic-ai-frameworks-you-should-know-in-2026) profiled ten agentic AI frameworks that developers should watch. LangGraph stands out for its explicit control over agent workflows and durable execution, making it suitable for long-running agents, customer-support systems, research assistants, and coding workflows. CrewAI, with its role-based approach, excels at fast multi-agent prototyping for research, reporting, and business automation, though role-based systems can become overly complex.

The OpenAI Agents SDK offers a lightweight, clean toolkit for building tool-using agents with straightforward handoffs, especially for teams already using OpenAI APIs. Google ADK and Mastra were noted as production-grade tooling for defining agents, tools, sessions, memory, evaluations, and deployment workflows. PydanticAI focuses more on reliable software engineering than role-playing multi-agent teams. These frameworks are not mutually exclusive; teams often start with a higher-level framework like CrewAI for prototyping and later adopt LangGraph for production durability.

What matters for European engineering leaders is the ability to self-host these frameworks under open licenses. LangGraph, CrewAI, and the OpenAI Agents SDK all permit local deployment, aligning with data sovereignty requirements. The code-first path does demand more engineering effort, but it rewards teams with the flexibility to customize every layer of the agent stack.

Multi-Agent Systems Become the Default Pattern

The July 2026 waves share a common thread: multi-agent systems are no longer an advanced niche. From visual builders to code frameworks, the ability to orchestrate multiple agents is now a standard feature. LangChain's Open Agent Platform uses an Agent Supervisor for multi-agent orchestration. Dify's agent beta supports multi-agent workflows without manual coding. AutoAgent automatically constructs multi-agent setups from plain English descriptions. Even TradingAgents (https://github.com/TauricResearch/TradingAgents), a specialized project for financial agents, reflects the broader industry trend toward agent collaboration.

One agent might handle customer inquiries, another manage inventory, and a supervisor agent coordinate the flow. Observability becomes critical at this scale, and the integration of tools like LangSmith and LangFuse across platforms shows that the ecosystem is maturing in operational readiness. The ability to self-host these multi-agent systems means that sensitive business data never leaves the company's infrastructure, addressing both compliance and performance concerns.

Choosing a Platform: Plain English or Code

How should an engineering leader at a European SMB choose? The answer depends on two factors: the team's coding proficiency and the need for deep customization. For pure agent building from plain English, the recommendations point to AutoAgent or LangChain Open Agent Platform. These platforms can convert natural language descriptions into functional agents and workflows. For teams with development resources who need durable, long-running agents, LangGraph or the OpenAI Agents SDK provide more control. No-code is a spectrum; several platforms reward custom code and are better called low-code. Licenses also matter: permissive MIT or Apache-2.0 licenses from AutoAgent, AnythingLLM, and Langflow offer the most flexibility, while fair-code licenses from n8n and FastGPT require careful review.

The July 2026 momentum is clear: open agent platforms are converging on a set of capabilities that make agent building accessible, scalable, and controllable. For European engineering leaders, this is the moment to evaluate how these platforms can translate into internal automation, customer-facing assistants, or data analysis workflows. The evidence from public projects and community activity is not a recommendation to adopt any single tool. It is a signal that the infrastructure is ready, and the time to experiment is now.

Frequently Asked Questions

Q: What is the difference between no-code and low-code agent platforms?

A: No-code platforms allow building agents through visual interfaces and plain-English prompts without writing code. Low-code platforms expose a visual builder but often reward custom code for advanced features, making them suitable for teams with some development capacity.

Q: Which open agent frameworks are best for multi-agent workflows?

A: LangChain Open Agent Platform, CrewAI, and LangGraph all provide robust multi-agent orchestration. AutoAgent also constructs multi-agent systems automatically from natural language descriptions.

Q: Are these open agent platforms production-ready?

A: Many have reached production maturity, with observability integrations and community battle-testing. The ability to self-host them under permissive licenses like MIT and Apache-2.0 further supports production deployment for European companies.

Q: How do licenses affect adoption for European SMBs?

A: Permissive licenses allow unrestricted commercial use and private modifications, which is essential for data control. Restrictive fair-code licenses, like the one used by n8n, impose conditions on commercial redistribution that may limit flexibility.

Further Reading

• AI Agent Orchestration for European Companies: A Decision and Governance Guide
• How to Run a 30-Day Pilot for an Open-Source AI Coding Agent
• Claude Code Across Every Device: Remote Control, Dispatch, and Agent View Explained

TL;DR: Anthropic launched Claude Opus 5 on July 24, 2026: near-frontier intelligence at half the price, aimed at long-running agents.

Anthropic launched Claude Opus 5 on July 24, 2026, and the pitch is unusual in both directions at once: near-frontier intelligence at half the price, and the company's safest model yet. For teams building on agentic coding workflows, this is the tier launch that matters most this month, because the Opus tier is where long-running agent work actually lives.

What launched

Anthropic positions Opus 5 as a thoughtful and proactive model that comes close to the frontier intelligence of Claude Fable 5 at half the price, with improvements aimed at coding and professional work. The positioning is explicitly about long-running agents: the tier designed for tasks that run for hours, not chat turns.

The launch also landed with unusually deep operational guidance. Anthropic published a prompting guide for Opus 5 alongside it, and the company's own context-engineering writeup for the Claude 5 generation reframes how developers should structure long agent runs. Simon Willison's launch-day coverage walks through both, and it is the fastest way to get past the headline.

The release cadence behind it

Opus 5 is not an isolated event. Anthropic opened a new Mythos class above Opus with Claude Fable 5 on June 9, shipped Claude Sonnet 5 on June 30, and brought Fable 5 back online on July 1 after a brief export-control suspension. Four meaningful tier events in six weeks, and the July 24 launch completes the picture: every tier now has a current-generation model.

The ecosystem absorbed the launch immediately. GitHub's July changelog has Claude Opus 5 available in Copilot, next to the Copilot cloud agent for Linear going generally available on July 23. Press coverage framed the launch the way Anthropic did: most of Fable's intelligence, half the price, safest model yet.

Why it matters for coding teams

If your team runs or evaluates agentic coding workflows, Opus 5 changes the evaluation math in two ways. First, the price curve: a tier that can plausibly run long agent loops at half the previous Opus cost changes which workloads are economically viable unattended. Second, the safety posture: a vendor explicitly optimizing a tier for safe autonomous behavior is a signal about where the market thinks agentic work is going.

The practical takeaway: if your evaluation harness was calibrated on the 4.x generation, rerun it. The tier boundaries moved, the price-performance curve moved with them, and the operational guidance for long agent runs is meaningfully different from six weeks ago.

Read further

• How to Run an AI Pilot to Production
• AI Governance Framework for European SMEs
• AI Readiness Assessment for European SMEs

TL;DR: July 2026 shipped a wave of agentic coding releases and the largest MCP spec revision since launch. What changed and why it matters.

Two things happened in July 2026 that belong in the same conversation. Agentic coding tools shipped a dense run of releases, and the Model Context Protocol, the connective tissue many of those tools rely on, reached the largest revision of its specification since launch.

The release wave

The clearest way to see the momentum is to line up what shipped in a single window. OpenAI announced GPT-5.6 on June 26 and made it generally available on July 9 across ChatGPT, Codex, and the API. Anthropic shipped Claude Sonnet 5 on June 30, and Claude Fable 5 came back online on July 1. OpenAI's Codex CLI reached version 0.145.0 on July 21, stabilizing its multi-agent V2 mode and adding MCP authentication elicitation alongside Bedrock support.

A daily discovery scan of public GitHub activity on July 25 tells the same story from the other side. Out of 170 repositories discovered and 141 normalized that day, the standout clusters were AI tooling, agent frameworks, and MCP servers: fast-moving projects such as cc-switch, superpowers, hermes-agent, dify, and TradingAgents. These repositories are evidence of where builder attention is going, not endorsements of any single project.

The MCP revision

The second event is structural. The Agentic AI Foundation's walkthrough of the MCP 2026-07-28 release candidate describes the largest revision of the protocol since launch. The specification is being redesigned around a stateless core, so the protocol works equally well on a developer's laptop and behind an enterprise API gateway. It introduces MCP Apps and Tasks, and it aligns authorization with OAuth.

The ecosystem context makes this more than a standards footnote. The protocol's maintainers announced the release candidate with beta SDKs already shipping, and press coverage this week puts the ecosystem past 10,000 published servers. When the wiring standard changes at that scale, every tool built on it feels it.

Why it matters for tool evaluation

If your team is evaluating agentic coding tools this quarter, the July wave changes the baseline of what to test. Multi-agent orchestration is no longer a demo feature; it shipped in a stable CLI release this week. And if your stack touches MCP, directly or through a vendor, the 2026-07-28 revision is the migration event to plan around: a stateless core, new application primitives, and an OAuth-aligned authorization model.

The practical takeaway is not to chase every release. It is to re-run your evaluation criteria against a market that moved twice in one month: once in the tools, and once in the protocol underneath them.

Read further

• How to Run an AI Pilot to Production
• AI Governance Framework for European SMEs
• AI Readiness Assessment for European SMEs

TL;DR: Open-source coding tools surge: AI editors and autonomous agents from independent maintainers. A guide for European engineering leaders.

In 2026, the way developers build software is being reshaped by a wave of open-source projects that go far beyond autocomplete. Tools like Claude Code, Cursor, and Aider, and frameworks such as the software periodic table with its 115 reusable software elements, allow small and mid-sized European companies to adopt AI-assisted development with more control and lower cost. This matters because engineering leaders can now choose from an array of transparent, community-driven alternatives that their teams can inspect, customize, and integrate without vendor lock-in. The breadth of independent maintainers entering the space signals a shift toward decentralized innovation in AI coding.

The Landscape of Open-Source Coding Assistants

Open-source coding assistants have evolved from simple line completion to full-fledged development partners. Cursor, an AI-native code editor, keeps the entire project in context and excels at inline editing, codebase-aware chat, and multi-file changes (https://www.turingpost.com/p/code-assistants). Aider, a terminal-based pair-programming tool, works directly with Git to edit files, commit changes, and handle refactoring tasks (https://www.turingpost.com/p/code-assistants). Cline is an open-source coding agent that operates inside the IDE; it can edit files, run terminal commands, and perform multi-step tasks with user approval (https://www.turingpost.com/p/code-assistants). These tools share a common trait: they are developed and maintained by independent contributors or small teams, not by large platform vendors. For small engineering outfits, this means the ability to fork, extend, or even self-host the tooling without waiting for a product roadmap.

Autonomous Agents and the Move Beyond Autocomplete

The category of autonomous agents goes deeper. A comprehensive survey on LLM-based autonomous agents (https://arxiv.org/abs/2308.11432) proposes a unified framework for constructing such agents, covering their application across social science, natural science, and engineering. These agents can plan, execute multi-step workflows, and evaluate their own output. In practice, Claude Code (https://github.com/anthropics/claude-code) can inspect large codebases, edit multiple files, run commands, and debug issues with minimal supervision. OpenAI Codex, built on the GPT-5.5 architecture, provides repository-level refactoring and debugging through a desktop app and CLI (https://www.turingpost.com/p/code-assistants). Even platforms like Replit have evolved into autonomous app builders that generate code, install dependencies, fix errors, and deploy without leaving the environment (https://www.turingpost.com/p/code-assistants). The shift is clear: from tools that suggest the next line to agents that own a task from specification to pull request.

Composition Frameworks: Building with Reusable Elements

A notable innovation from the independent maintainer community is the software periodic table (https://github.com/NullLabTests/software-periodic-table). It defines a machine-readable ontology of 115 recurring software elements, organized into six families: Objects, Properties, Actions, Interfaces, Intelligence, and Rules. Coding agents can consume this ontology to retrieve relevant atoms and emit a composition plan along with minimal code. This approach treats application features not as monolithic scripts but as structured assemblies of proven patterns. It aligns with the broader trend in open-source AI toward composability and transparency (https://en.wikipedia.org/wiki/Open-source_artificial_intelligence). For teams evaluating whether to adopt these tools, the presence of such frameworks signals that the underlying models and their prompts are becoming more predictable and auditable, a critical factor when security or compliance is at stake.

Open-Source AI: A Brief History and the Promise of Transparency

Open-source artificial intelligence has roots that predate the current LLM boom. The concept gained traction with early shared implementations like ELIZA in 1977 and the Free Software Foundation in 1985 (https://en.wikipedia.org/wiki/Open-source_artificial_intelligence). The 1990s saw the CMU Artificial Intelligence Repository, and in the 2000s, frameworks like Torch (released in 2002) laid the groundwork. OpenAI itself was founded in 2015 with a mission to create open-source AI (https://en.wikipedia.org/wiki/Open-source_artificial_intelligence). Today, open-source AI projects include large language models, machine translation tools, and chatbots. The key advantage for engineering leaders is transparency: with access to model weights, training data, and source code, teams can audit for biases, tailor to domain-specific needs, and avoid the "openwashing" criticized in some commercial offerings (https://en.wikipedia.org/wiki/Open-source_artificial_intelligence).

What This Means for Small and Mid-Sized Companies

The combination of open-source coding assistants, autonomous agents, and composable frameworks creates a new procurement calculus. Instead of a per-seat SaaS license from a single vendor, a ten-person team can run Aider alongside a self-hosted model, use Cline for complex refactoring inside VS Code, and reference the software periodic table to standardize how features are expressed. This composability reduces the risk of tooling stagnation and aligns costs with actual usage. It also shortens the feedback loop between developer intent and agent action, because maintainers often respond directly to community issues rather than routing through enterprise support queues.

Frequently Asked Questions

Q: How do open-source coding assistants compare with proprietary tools like GitHub Copilot?

Open-source alternatives such as Cursor, Aider, and Cline offer similar capabilities, including inline completions and multi-file edits, but give teams full visibility into the code and the option to self-host. They are often developed by independent maintainers and can be customized to internal workflows (https://www.turingpost.com/p/code-assistants).

Q: Are autonomous coding agents ready for production use?

Tools like Claude Code and OpenAI Codex are already handling repository-level refactors and debugging. The survey on LLM-based autonomous agents (https://arxiv.org/abs/2308.11432) notes growing adoption across engineering fields, though evaluation strategies are still maturing. Many teams start with supervised use, where the agent proposes changes and a developer approves them.

Q: What is the software periodic table and why does it matter?

It is a finite ontology of 115 software elements designed for LLM-based coding agents (https://github.com/NullLabTests/software-periodic-table). By breaking features into Objects, Actions, Interfaces, and other families, it helps agents compose solutions from known patterns, making output more predictable and auditable.

Q: What are the risks of using open-source AI coding tools?

The main risks relate to model performance, security of self-hosted deployments, and the overhead of evaluating community-maintained projects. The open-source AI movement emphasizes transparency, but teams should still audit model training data and update practices (https://en.wikipedia.org/wiki/Open-source_artificial_intelligence).

Further Reading

• The Open-Source AI Stack Engineering Leaders Should Watch in 2026
• Coding Agents Are Splitting Into Two Camps: Terminal-Native vs Workflow-Native
• Harness Engineering: How to Build Quality Gates from PR to Production for AI Coding Agents

TL;DR: Solo: one mono repo, unlimited tools, zero approvals. Enterprise: many repos, procurement, compliance gates. Two realities of AI agent adoption.

Why this matters now: the gap between solo and enterprise AI adoption decides which 10-50 person team ships AI-assisted features this quarter and which one is still in procurement when the EU AI Act enforcement deadline lands (S1).

A solo developer installs Claude Code, connects it to their mono repo, and ships a feature before the afternoon is out. An enterprise developer submits a procurement request for Copilot Enterprise at $39/user/month (S4), waits weeks for security review, gets budget approval for a block of seats, discovers it does not work with their internal toolchain, and goes back to writing code manually while the request cycles through another round of vendor assessment.

These are both real workflows happening right now, in May 2026, in the same industry. The tools are the same. The experiences could not be more different. Why this matters for your team: every week of procurement delay is a week your competitors ship AI-assisted features you cannot match, and every shadow-AI tool a developer installs without governance is a compliance exposure the EU AI Act (S1) now treats as your liability.

This is the defining split in small team AI adoption vs enterprise reality in 2026. This article is about that gap: what causes it, where each side has genuine advantages, and what the 10-50 person team in the middle can learn from both extremes.

The Solo Developer Reality: Mono Repo AI Agents and Zero Friction

One Repo, Zero Friction

The solo developer or 2-3 person team operates in a world where:

• One mono repo contains everything. The AI agent has full context. No cross-repo dependencies to navigate, no service boundaries to understand, no microservice mesh to reason about.
• Tool adoption takes minutes. A one-line install, no procurement, no security review, no vendor assessment. If it does not work, uninstall it and try the next one.
• Budget is personal. About \(20/month for ChatGPT Plus, which now includes the Codex CLI (S7). Nothing at all for the free tier of Gemini CLI. From about \)100/month for Claude Max if you need the heavy model (S6). The decision maker is the user.
• Context switching is minimal. A single developer knows the entire codebase. The AI agent's suggestions are evaluated by someone who understands every file. No handoffs, no review queues, no I need to check with the team.
• Experiments are free. Try a new agent mode. Run several workers in parallel. Route a cheaper model through an open-source client. If it breaks something, reset the branch and you are back. Nobody else is affected.

The Typical Solo Stack (May 2026)

MacBook
├── Claude Code (primary agent, large context window)
├── Kimi CLI (secondary, cheap, fast, parallel swarms)
├── Codex CLI (included with ChatGPT Plus)
├── One mono repo (everything in one place)
├── GitHub Free (2,000 Actions minutes) (S5)
└── Total cost: roughly $20-200/month depending on usage

What Solo Developers Get Right

Speed of adoption. By the time an enterprise finishes its vendor assessment, the solo developer has tried several tools, settled on a couple, built custom skills, and published the workflow as a blog post.

Full-context advantage. An AI agent working in a single repo with a clear CLAUDE.md understands the entire project. It does not need to query a sprawl of microservices to understand a data flow. The mono repo is the ultimate context window. This is the mono repo AI agents advantage in its purest form.

Willingness to experiment. Solo developers try things that enterprises cannot: running newer or foreign-made models, using experimental features, mixing providers across a single open-source client. The risk tolerance is personal, not institutional.

The Enterprise Reality: GitHub Copilot Enterprise Procurement

Hundreds of Repos, Maximum Friction

The enterprise developer operates in a world where:

• Hundreds of repositories spread across many teams. No single person understands the full system. Cross-repo dependencies are documented (if you are lucky) in wiki pages that were last updated well over a year ago.
• Tool adoption takes weeks to months. Security review, data residency assessment, procurement approval, budget allocation, license negotiation, pilot scope definition, success criteria agreement, rollout plan, training schedule. Each step has a different owner.
• Budget requires approval. Copilot Enterprise at \(39/user/month (S4) for a 200-developer organisation runs to about \)93,600/year. That is a line item that requires VP-level sign-off, finance approval, and a business case with projected ROI. The $20/month ChatGPT Plus (S7) that the solo developer uses without thinking is a rounding error that an enterprise cannot process without a PO.
• Developers wait for specs. In a large organisation, a developer does not decide what to build next. Product managers write requirements. Architects design solutions. Developers implement specs. The AI agent cannot help you write code faster if you are waiting weeks for the spec to be finalised.
• Experiments require approval. The AI coding tools enterprise approval path runs through InfoSec, Legal (data processing terms), Procurement (vendor assessment), and IT (compatibility with the existing toolchain). The answer comes back weeks later, by which time the tool has shipped several major updates.

The Typical Enterprise Stack (May 2026)

Corporate laptop (managed by IT)
├── GitHub Copilot Enterprise ($39/user/month, pre-approved) (S4)
├── One approved IDE (VS Code, configured by IT)
├── Hundreds of repos across many teams (no single-repo context)
├── GitHub Enterprise ($21/user/month, 50,000 Actions minutes) (S5)
├── Internal deployment pipeline (Jenkins/ArgoCD, not Actions)
├── Jira for task tracking (mandatory)
├── Confluence for documentation (mandatory)
├── Approved tool list: Copilot. That is it.
└── Total cost: about $60/user/month across 200 developers,
    roughly $144,000/year (and half the developers still cannot
    use it because their repos are not yet onboarded)

What Enterprises Get Right

Governance by design. When an enterprise deploys Copilot Enterprise, it comes with SSO, audit logs, IP indemnification, data residency guarantees, and a legal framework. The solo developer using Claude Code via a personal API key has none of this.

Security posture. Enterprise tool adoption is slow because the security review is real. Data residency, SOC 2 compliance, GDPR data processing agreements, vulnerability scanning. The solo developer who installs a new CLI without reading the data processing terms is taking a risk they may not understand.

Scale discipline. A large enterprise standardising 200 developers on the same tool, the same configuration, the same AGENTS.md, and the same review guidelines is consistency at scale. Those same 200 developers each choosing their own AI tool is chaos.

Knowledge preservation. The enterprise's documentation, even when outdated, preserves institutional knowledge. The solo developer's knowledge lives in their head. When they leave, it leaves with them.

AI Governance for Small Teams and Large: Where Each Side Fails

Solo Developers Fail On

Governance debt. I will add security review later becomes I shipped hundreds of commits without reviewing any of them for secrets, PII, or compliance violations. BCG and Harvard Business School research on GenAI's jagged frontier (S2) finds that error rates rise when AI tools are used outside their capability boundary, and solo developers have no review safety net to catch the difference.

Context bus factor. A single developer knows everything. When they get sick, go on holiday, or burn out, the project stalls completely. The AI agent cannot replace the human's understanding of why decisions were made.

Compliance blind spots. The EU AI Act's high-risk requirements apply to organisations of any size. A solo developer using AI to screen job applicants is subject to the same compliance obligations as an enterprise. The difference is the enterprise has a compliance team and the solo developer probably does not know the obligation exists.

Enterprises Fail On

Adoption speed. The procurement cycle is the bottleneck. By the time Copilot Enterprise is approved and deployed, competitors (including solo developers and small teams) have been shipping with AI agents for months. The competitive disadvantage is not in the tool, it is in the time to deploy it.

Developer frustration. Developers know what tools exist. They can see solo developers and small teams shipping far faster with tools the enterprise has not approved yet. The result: shadow AI. Microsoft's Work Trend Index found that 78% of AI users bring their own AI tools to work, rising to 80% at small and medium-sized companies (S3), and the gap between the AI tools developers are using and the AI tools the organisation has approved keeps widening.

Over-engineering the solution. An enterprise does not need a multi-month pilot programme to evaluate whether AI coding assistants are useful. The evidence is conclusive. What it needs is a lightweight approval gate, a clear acceptable use policy, and a short deployment. The pilot programme is often a delay mechanism, not an evaluation mechanism.

Spec-driven paralysis. In a world where AI agents can implement a feature in minutes, waiting weeks for a spec is the dominant cost. The specification process itself needs to be rethought, not eliminated, but accelerated to match the new implementation speed.

The 10-50 Person Team: Where the Real Advantage Sits

This is where most of our audience sits: European mid-sized companies with 10-50 employees. You have the best opportunity:

Take from the solo developer

• Speed of tool adoption. Evaluate and deploy in days, not months. Your team is small enough that a Slack message can replace a procurement workflow.
• Mono repo or few repos. A growing software team typically has only a handful of repos. This is the sweet spot for AI agents: enough context to be useful, not so many repos that context fragments.
• Personal budget flexibility. A CTO can approve a tool in a single conversation. No PO required.
• Willingness to experiment. Try multiple tools. Run more than one in parallel. Compare. Settle on what works.

Take from the enterprise

• Write your AGENTS.md. Even with a handful of developers, codify your standards. The AI follows what you write down.
• Establish a minimal acceptable use policy. One page. What tools are approved, what data can be shared, what requires human review. Prevents shadow AI before it starts.
• Use branch protection. Required reviews, required CI checks, no direct push to main. This is free governance.
• Document decisions. ADRs, CLAUDE.md, ROADMAP.md. When the AI agent or a new team member joins, the context is there.

The SME Stack (Recommended, May 2026)

Team of 10-15 engineers
├── Claude Code (primary, Max plan)
├── Codex CLI (included with ChatGPT Plus, secondary/review)
├── AGENTS.md + CLAUDE.md (governance docs committed to repo)
├── GitHub Team ($4/user/month, 3,000 Actions minutes) (S5)
├── Branch protection (required reviews + CI green)
├── Codex GitHub connector (automated PR review)
├── A handful of repos (manageable context)
├── Acceptable use policy (one page)
└── Total cost: roughly $150-300/month for the team
    (comparable to the solo developer, with enterprise governance)

The Pricing Reality Nobody Talks About

The list prices are public: GitHub's plans run from Free (2,000 Actions minutes) to Team (\(4/user/month) to Enterprise (\)21/user/month) (S5).

The cost per developer drops sharply at enterprise scale, but the time to first value runs far longer. For an SME the economics land best: near-enterprise tooling at near-solo speed.

What Changes If You Are in the Middle

If you are a CTO, Head of Engineering, or founder leading a 10-50 person engineering organisation reading this, here is what to do this week:

1. Audit what your team is already using. They are using AI tools, the question is whether you know about it. Ask. No judgment. Just inventory.
2. Pick one primary tool and approve it. Claude Code, Codex CLI, or Copilot. Do not let the team fragment across a pile of tools.
3. Write an AGENTS.md. Half an hour. Commit it. Every AI session now follows your rules.
4. Enable branch protection. Required reviews + CI checks. Free. Takes a few minutes on GitHub.
5. Set a budget. A modest per-developer monthly allowance covers a primary tool plus GitHub Team. This is the developer experience AI tools 2026 offer, without the enterprise overhead.

You do not need an enterprise procurement process. You do not need a multi-month pilot. You need a decision, a policy, and branch protection. That is the SME advantage.

Frequently Asked Questions

Can a solo developer match enterprise code quality with AI tools?

On individual features, often yes, sometimes better, because the solo developer has full context and zero handoff friction. On sustained quality at scale (consistent standards, security review, compliance), no. That requires governance structures that scale beyond a single individual.

Why do enterprises not just let developers choose their own AI tools?

Data residency, IP exposure, compliance obligations, and consistency. If 200 developers each use a different AI tool with different data handling terms, the legal exposure is unmanageable. Standardisation is not bureaucracy, it is risk management.

Is the mono repo advantage real for AI agents?

Yes. An AI agent with full repo context makes fewer errors, understands more cross-cutting concerns, and needs less human guidance. The multi-repo enterprise setup fragments context. Some teams mitigate this with MCP servers that give agents cross-repo visibility, but it is not as seamless.

How do SMEs avoid becoming the worst of both worlds?

By being intentional. The risk is adopting solo-developer speed without enterprise governance (chaos) or adopting enterprise governance without solo-developer speed (paralysis). The answer: lightweight governance (AGENTS.md, branch protection, acceptable use policy) deployed at startup speed (this week, not this quarter).

What about the EU AI Act? Does company size matter?

The EU AI Act does not have an SME exemption for high-risk system obligations. However, SMEs benefit from reduced fine ceilings, access to regulatory sandboxes, and the practical reality that most SME AI use cases are minimal-risk. The compliance burden is proportionate, but it is not zero.

Further Reading

• EU AI Act: What European SMEs Must Do Before August 2, 2026
• Every AI Coding Agent CLI in April 2026 Compared
• We Built the Engine But Not the Chassis: AI Team Velocity
• Codex GitHub Connector: Automated PR Reviews That Work
• Claude Code Across Every Device: Remote Control, Dispatch, and Agent View

The SME Advantage Is Real, If You Act on It

You are small enough to move fast and large enough to need governance. That is not a weakness; it is the optimal position for AI agent adoption in 2026. The solo developer moves faster but accumulates governance debt. The enterprise moves safer but loses months to procurement.

You can have both: deploy this week, govern from day one.

If your team needs help designing the governance layer, AGENTS.md, acceptable use policy, tool selection, review automation, start with an AI Readiness Assessment. The process maturity and governance dimensions are specifically designed for this decision.

For ongoing advisory as your AI tooling evolves, explore our Fractional CAIO retainer: monthly tool evaluation, policy updates, and governance oversight for teams that move fast but want to stay safe.

Follow First AI Movers on LinkedIn for practical AI frameworks and decision guides.

TL;DR: Developers keep shipping cybersecurity agents, CLI tools, and forecasting models while your business needs invoice automation: how to read the gap between GitHub trending and real SME value.

This week, the most-starred new projects on GitHub trending were a cybersecurity skill library for AI agents, a command-line reader that pulls Twitter, Reddit, and YouTube with no API fees, an LLM-powered stock-analysis dashboard, and Google's time-series forecasting model, TimesFM (S1). Every one of them is a developer tool. Not one of them is what your business actually needs this quarter.

Meanwhile, your business needs someone to automate the invoice processing that eats hours of your finance person's week. Your customer service team is answering the same handful of questions over and over. Your CTO wants to know whether AI is worth the budget conversation with the board.

This is not a criticism of what developers build. It is an observation about the gap between what is technically trending and what is practically valuable for a European SME with around 15 employees and a technology budget on the order of €500 per month. Understanding this gap, the real divide between what AI tools business vs developer audiences actually want, is the difference between chasing hype and capturing value.

What Trended on GitHub This Week (And What AI Trends Matter for Small Business)

The Top Repos (Week of June 25, 2026)

What These Repos Have in Common

They are developer tools built for developers. They assume you have a terminal, understand git, can install packages, and know what an MCP server is. They solve real problems, but the problems they solve are developer problems.

Not one of the top trending repos this week solves:

• Invoice processing
• Customer email triage
• Sales lead qualification
• Content publishing
• Compliance documentation
• Employee onboarding
• Inventory management

These are the problems that European SMEs actually have. And they are solvable with AI, just not with the repos that trend on GitHub.

What Your Business Actually Needs: Developer Tools and Business Needs

The Translation Layer

The value of trending repos is not in using them directly. It is in understanding what they signal about where AI capability is heading, and finding the tools that package that capability for non-developers. This is what GitHub trending practical business use really means: reading the signal, not running the repo.

There is no shortage of GitHub repos useful for SME teams in theory. The gap is that almost none of them are packaged for a non-developer to actually use, and that packaging is where your value lives.

The Three Layers of AI Value

Understanding where trending repos sit helps you decide what to pay attention to and what to ignore.

Layer 1: Infrastructure (For Developers)

This is where GitHub trending lives. Frameworks, protocols, model weights, CLI tools. You do not use these directly unless you are a developer or have one.

Examples from this week: the code intelligence MCP server, the cybersecurity skill framework, the TimesFM model.

What to do: ignore the repos. Watch for the products built on top of them over the next couple of quarters.

Layer 2: Products (For Technical Business Users)

These are the tools built on Layer 1 infrastructure, packaged with interfaces, pricing, and support. This is where value gets captured.

Examples: Tidio (customer service AI), Rossum (invoice processing), HubSpot AI (lead scoring), Make.com (workflow automation).

What to do: evaluate one per quarter. Deploy the one that solves your most expensive manual workflow.

Layer 3: Outcomes (For Business Leaders)

This is what you actually care about: fewer hours wasted, more leads converted, faster customer response, lower compliance risk.

The gap: most AI content is written about Layer 1 (what developers build) or Layer 2 (what products exist). Almost nobody writes about Layer 3, the actual business outcome for a company your size. That is what we focus on.

This Week's Actionable Takeaway: AI Hype and Practical Value

If you took exactly one action based on this week's GitHub trends, it should be this: separate AI hype vs practical value by watching the integration layer, not the leaderboard.

The Model Context Protocol is consolidating into the industry standard. MCP began as an open standard from Anthropic for connecting AI assistants to tools and data (S2). Within about a year it had been adopted by OpenAI, Google, Microsoft, and Amazon and moved into a vendor-neutral foundation under the Linux Foundation (S3). The major coding CLIs now speak it, Claude Code, OpenAI's Codex, Google's Gemini CLI, and Moonshot's Kimi CLI (S5), and even OpenAI is consolidating its own surface: it is sunsetting the Assistants API, with a removal date of August 26, 2026, in favour of its newer Responses API (S4), which itself now supports MCP.

What this means for you: any AI tool you adopt from here on should support MCP. This is not a developer concern, it is a procurement criterion. MCP-compatible tools will interoperate. Tools that ignore the standard will become isolated.

Concrete action: when evaluating any AI tool, ask the vendor whether the product supports MCP. If the answer is no, ask when. If the vendor does not recognise the term at all, the vendor is behind.

Why This Gap Exists

Developers Solve Developer Problems

GitHub trending is driven by developer activity. Developers star repos that help them code faster, manage agents better, or build new capabilities. These are valid problems, but they are not your problems.

A small company does not need a multi-agent fleet manager. It needs a chatbot that answers its most common customer questions so a teammate can stop spending half the day on email triage.

The Product Gap Takes Time

The pattern is consistent: a capability appears on GitHub, developers adopt it, startups build products on it, and business users can finally access it. This cycle takes roughly six to twelve months for broad categories, and three to six months for fast-moving ones. The cybersecurity AI skills framework trending today will surface as a compliance SaaS product by early 2027.

Your job as a business leader is not to use the repo. It is to recognise the signal and prepare for the product.

Content Is Written for Builders, Not Buyers

The vast majority of AI content online is written by developers for developers: benchmark comparisons, framework evaluations, model performance charts. This content is useless if you do not write code.

The sliver written for business leaders is mostly vendor marketing, Our platform transforms your business with AI, with no numbers, no practical steps, and no honesty about what does not work.

The content that actually helps, practical guides with real costs, real timelines, and real limitations, is rare. That is the gap we fill.

How to Read GitHub Trending as a Business Leader

A monthly, fifteen-minute exercise:

1. Open GitHub Trending in the weekly view.
2. Scan the top ten repositories, read only the one-line description.
3. Ask three questions:
   • Is this solving a problem my business has? (Usually no.)
   • Is this building infrastructure that will become a product I can use? (Sometimes.)
   • Does this signal a shift I should prepare for? (Occasionally, MCP, sovereign AI, agent fleets.)
4. Ignore everything else. Your time is worth more than chasing developer trends.

Most trending repositories signal nothing your business needs. Only a small share point to a shift worth preparing for, and telling them apart is the whole skill.

Frequently Asked Questions

Should I tell my CTO to look at GitHub trending?

Yes, but frame it correctly. The question is not whether you should use a given repo. It is what the trend signals about a capability you should plan for. GitHub trending is market intelligence, not a shopping list.

How do I know when a trending capability becomes a business product?

Watch for three signals: a startup raising funding to productise the capability, an existing SaaS adding it as a feature, or a low-code platform such as Make.com or Zapier adding an integration. When any of these happens, the capability is ready for business use.

Is there a version of GitHub trending for business tools?

Not exactly, but Product Hunt and Capterra track business tool launches. The pattern tends to run from trending on GitHub today, to a Product Hunt launch within a couple of quarters, to review-site coverage later in the year.

My developer wants to use a trending repo in our product. Should I let them?

Evaluate it like any dependency. Is it actively maintained? Does it have a licence your business can use? Is there more than one maintainer? Does it have tests? If the answer to all of those is yes, it is reasonable. If not, it is a risk.

Further Reading

• AI Use Cases That Pay for Themselves in the First Quarter
• The Honest AI Adoption Guide: Every Fear You Have Is Valid
• MCP Won the Agent Protocol War: Migrate Before August
• Every AI Coding Agent CLI Compared
• Solo Developer vs Enterprise: AI Agent Adoption Realities

We Translate the Signal

You do not need to read GitHub. You need someone who reads GitHub, understands what matters for your business, and tells you what to do about it, in plain language, with real numbers.

Take our AI Readiness Assessment to see where your company stands. Or talk to us directly about which AI capabilities are worth your attention and which are developer noise.

Follow First AI Movers on LinkedIn for practical AI frameworks and decision guides.

TL;DR: Your AI pilot is expensive because you shipped the first approach that worked. Here is how European SMEs right-size AI cost without losing the result.

If your AI pilot is over budget, the cause is usually not the technology. It is the architecture decision you made on day one and never revisited.

Most teams ship the first approach that works. It works, the demo lands, the project moves on. The problem: the first approach that works is almost always the most expensive one, a premium model on every task, a fresh inference call for every record, no caching, no batching, no clustering. The cost only becomes visible when the pilot meets real volume.

A recent hackathon gave a clean, public example of the alternative discipline. The lesson translates directly to a small company trying to make AI pay for itself.

The Sim Francisco lesson: same result, a fraction of the cost

At Anthropic's Claude Opus 4.8 Build Day hackathon in San Francisco on 13 June 2026, 310 builders, selected from roughly 1,500 applicants, had 12 hours and $500 of credits each to ship something real (S1).

One of the three winning projects, Sim Francisco (it placed second), was a synthetic digital twin of San Francisco's population, built by UC Berkeley students Tanmayi Priya Dasari and Tejas Prabhune (S1). The naive way to build it is obvious: create 10,000 synthetic residents and run one AI inference call per resident to predict how each would behave. It works. It is also expensive at scale.

They did not settle for that. Instead, they used an evolutionary clustering algorithm to collapse 10,000 synthetic residents into roughly 300 representative personas, then reasoned over the personas. That single engineering move cut cost by 10-100x (S1).

The accuracy held. Sim Francisco forecast San Francisco's 2024 presidential result at 81.3% Democratic (actual 83.8%) and Proposition A at 70% (actual 70.38%). A model that was 10 to 100 times cheaper to run produced forecasts within a couple of points of reality (S1).

Their advice to other builders was one sentence every SME leader should pin to the wall (S1):

Don't settle for the first approach that works, especially when it's expensive.

Why it works is the most expensive moment in an AI project

The first approach feels like success. The demo runs, the output looks right, the team is relieved. That relief is exactly the trap. It works is the moment you stop optimizing, and the moment your future bill gets locked in.

The first approach is expensive for predictable reasons. It usually means:

• The most capable (and most costly) model used for every task, including trivial ones.
• One inference call per item, with no batching or grouping of similar work.
• No caching, so identical or near-identical requests get paid for again and again.
• No clustering, so 10,000 things that behave like 300 things still cost like 10,000 things.

None of these are visible in a demo. All of them are visible in a monthly invoice once volume arrives. For a small company, that gap between the pilot bill and the production bill is where AI projects quietly get cancelled.

Right-sizing AI workflows: translating the cluster trick to real SME work

You are not forecasting an election. But the underlying move, find the structure in your data and stop paying per item when you can pay per pattern, applies to almost every AI workflow a small company runs.

Customer service and support triage

The naive approach: send every incoming message to a premium model and generate a bespoke answer. The right-sized approach: cluster incoming questions into recurring intents. A large share of support volume is variations on a handful of questions. Route those to cached or templated answers, and reserve the expensive model for the genuinely novel cases. Same customer experience, a fraction of the per-message cost.

Document and invoice processing

The naive approach: one full premium-model pass per document. The right-sized approach: a cheap, fast model handles classification and extraction for the standard majority, and the expensive model is reserved for exceptions and edge cases. You are matching model cost to task difficulty instead of paying top rate for routine work.

Reporting, summaries, and internal knowledge

The naive approach: regenerate every summary on demand. The right-sized approach: cache stable outputs, batch overnight, and only recompute what actually changed. Most internal content does not change between two reads, paying to regenerate it does.

The pattern is the same one Sim Francisco used: collapse the redundant work, reserve the expensive path for what genuinely needs it.

AI pilot cost optimization: from first approach to right-sized approach

The right-hand column is not a downgrade. Sim Francisco proves the point: the cheaper architecture produced forecasts within roughly two points of the expensive one. The goal is not to spend less and accept worse. It is to spend less and keep the result.

A cost-driver checklist before you scale any AI pilot

Before you move a working pilot to production, walk this list. Each yes is money you are likely overspending.

• Are you using your most capable, most expensive model on tasks a cheaper model could handle?
• Are you paying a full per-call inference cost on every item when similar items could be batched or grouped?
• Are you re-computing identical or near-identical requests instead of caching them?
• Is there natural structure in your data, repeated intents, document types, personas, that you are not collapsing?
• Do you know your projected cost at 10x and 100x your current volume, not just today's volume?
• Did anyone revisit the architecture after the first version worked, or did it works end the conversation?

If you cannot answer the last two, you have shipped the first approach, and you are probably overpaying.

What this means under the EU AI Act

Cost discipline and compliance discipline reinforce each other in 2026. Under the EU AI Act, the transparency obligations, telling people when they are dealing with AI and labelling AI-generated content, become enforceable on 2 August 2026, while the high-risk system obligations were pushed back to December 2027 and beyond after a 2026 simplification package (Gibson Dunn) (S2). Whichever obligations apply to you, right-sizing forces you to map exactly which model touches which task and which data, the same documentation and data-flow clarity the Act expects. A messy architecture that routes everything through the premium model is both more expensive and harder to govern. Cleaning it up does double duty.

How First AI Movers helps

This is the work we do: a practical LLM cost reduction strategy for real budgets. We come into a working, and expensive, AI setup and find the cheaper approach you have not tried yet: the model you are overusing, the calls you could batch, the requests you could cache, the structure in your data you could cluster.

The promise is specific and credible: the same outcome at a fraction of the spend, so a small company gets enterprise-grade results without an enterprise-grade bill. We are the guide; the savings stay yours.

Frequently Asked Questions

Does a cheaper AI approach always mean lower accuracy?

No. The Sim Francisco example is the clearest counter-evidence: a model that was 10-100x cheaper to run still forecast the presidential vote at 81.3% against an actual 83.8%, and a local proposition at 70% against 70.38% (S1). The skill is in finding structure and redundancy to remove, not in lowering quality. Designed well, the cheaper architecture matches the expensive one.

How do I know if my company shipped the first approach?

Ask whether anyone revisited the architecture after the first version worked. If it works ended the conversation, you almost certainly shipped the first approach. The tells are a premium model on every task, one call per item, and no caching or batching, all invisible in a demo, all visible in a production invoice.

What is the single biggest AI cost driver for small companies?

For most SMEs it is using the most capable, most expensive model on routine work that a cheaper model handles just as well. Matching model cost to task difficulty is usually the largest and fastest saving, before you even get to batching, caching, and clustering.

When should I optimize AI cost, before or after launch?

Get a working version first, then optimize before you scale. Optimizing too early wastes time on a design you may abandon. But moving to production volume without revisiting the architecture locks in the expensive path. The right moment is after it works and before you scale.

Further Reading

• AI use cases that quickly pay for themselves
• An honest guide to European SME leaders' AI adoption fears
• What three hackathon winners teach small companies
• GitHub trending vs real business needs

Find the Cheaper Approach You Haven't Tried Yet

Most AI overspend is fixable without losing the result. Start with our AI Readiness Assessment to see where your spend is going, then talk to us about AI consulting. We find the cheaper approach you haven't tried yet, same outcome, a fraction of the spend.

Follow First AI Movers on LinkedIn for practical AI frameworks and decision guides.

TL;DR: Most failed AI pilots die from no plan, not bad tech. Learn the map-first AI project planning method that lets small European teams ship working AI.

The single biggest predictor of whether your AI pilot works is not the model you choose, the vendor you hire, or the budget you approve. It is whether someone wrote down, before any tool was opened, exactly which workflow the AI must fix, what fixed looks like, and when to kill the project. The teams that plan win. The teams that start typing into an AI tool and see where it goes burn cash and quietly abandon the pilot a quarter later.

That pattern showed up vividly at a recent Anthropic event, and it maps almost perfectly onto why most small-company AI projects stall.

The hackathon that proved planning beats horsepower

On 13 June 2026, Anthropic ran a Claude Opus 4.8 Build Day hackathon in San Francisco (S1). The numbers were stark: 310 builders selected from roughly 1,500 applicants, 12 hours on the clock, and $500 in model credits each (S1). Everyone had the same frontier model. Everyone had the same time. The constraint was identical for all 310 people in the room.

The winner, a project called Tekton, was built by just two people, designer Holly Tang and Austin Burgess, who had met a month earlier in line for coffee at a Code with Claude event (S1). Their project digitally reconstructed historic buildings, including Tang Dynasty architecture and the spire of Notre-Dame, across 339 incremental construction states, with every single component traceable back to source evidence (S1). It was rigorous, deep, and finished. A two-person team beat a room of more than 300 competitors.

What they did differently

They did not start building. They started by mapping.

Before writing code, the pair wrote a complete PRD, a product requirements document. As Austin Burgess put it, "We built an entire PRD and a Notion board with around 50 tickets, one for each specific task" (S1). Only then did they execute, running separate workflows in parallel because the spec told them exactly which pieces were independent and could move at the same time. Their lesson, distilled: map the whole project before you build any of it.

The lesson is not that AI is powerful. Everyone in that room had the same powerful AI. The lesson is that the planning discipline, the spec written before the build, is what converts raw capability into a finished, defensible result under a hard deadline. The team with the clearest map shipped the most complete project.

Why this matters more for a small company than a large enterprise

A large enterprise can afford a failed AI pilot. It has slack, budget lines, a spare quarter, a team that can absorb a write-off. A European SME with 10 to 50 employees has no such cushion. When a small company spends three months and a real budget on an AI tool that ends up doing a bit of everything, badly, that is not a learning experience. It is a hole in the year.

So the planning discipline that won a hackathon is not a nice-to-have for you. It is the difference between a working deployment and an expensive toy you stop opening.

The real reason most AI pilots fail

It is rarely the technology. The models available in 2026 are more than capable for the operational workflows most SMEs need. The failure pattern is almost always upstream of the tool:

• No spec. Someone opened the AI tool and started prompting, with no written definition of what it had to accomplish.
• No defined outcome. Improve our customer support is a wish, not a target. Nobody could say afterwards whether it worked.
• No scope boundary. The pilot drifted, first it answered emails, then it drafted quotes, then it tried to update the CRM, and did all of it half-well.
• No kill criterion. With no agreed line for this isn't working, stop, the pilot limped on, consuming time and goodwill until it was quietly dropped.

The build-first instinct feels productive. It is the most common way to waste an AI budget.

The two paths: build-first and map-first

The Tekton team did not have more time or a better model than anyone else. They had a map. That is the entire edge, and it is fully available to a small operations team that has never run an AI project before.

The minimum viable AI spec: a checklist a non-technical leader can run

You do not need a technical PRD with 50 tickets. You need five answers, written down and agreed before any tool is bought or any prompt is typed. If you cannot answer all five, you are not ready to build yet, and that is useful to know before you spend. This is the minimum viable AI spec, and it is the shortest honest answer to how to plan an AI project.

How to use the checklist in practice

Pick one painful workflow, not a category. Not automate operations. Instead: draft first-response replies to inbound support emails in our top three languages. One workflow, clearly bounded. The boundary is the point, it is what stops the AI pilot scope creep that kills pilots.

Attach a number before you start. If today a task takes your team eight hours a week, the outcome is cut this to under two hours a week within six weeks. Now success is observable by anyone, not a matter of opinion. A pilot with no number cannot be judged, so it never ends cleanly.

Check the data honestly. Most SME AI pilots stall not on the model but on the inputs, the information is scattered across inboxes, spreadsheets, and someone's head. If the data is not reachable, that is your first project, and the spec just saved you from discovering it three weeks in.

Write the guardrails as plainly as the goal. Under the EU AI Act, whose prohibitions and general-purpose AI obligations are already in force, with high-risk obligations phasing in (S2), knowing exactly what your system does, what data it touches, and where a human reviews its output is not just good practice; it is part of staying on the right side of obligations that increasingly carry real weight. A spec that names the human-in-the-loop point is a compliance asset, not bureaucracy.

Agree the kill line out loud. The hardest discipline is deciding, in advance, the result that means stop. A pilot you are allowed to stop is cheap. A pilot nobody can stop is the one that drains the year.

Plan first, then let the work run in parallel

Here is the part that the Tekton story makes concrete and that small teams routinely miss: planning first is what enables speed, not what slows it down. Because the team had a complete map, they could see which pieces were independent and run separate workflows in parallel without tripping over each other. The spec is what made the parallelism safe.

For an SME, the equivalent is this: once the one workflow is specified, you often find it splits into a handful of independent steps, data preparation, the AI drafting step, the human review step, the hand-off to your existing system. With a map, two people can work those steps at once. Without a map, the same two people block each other, redo work, and produce something nobody can quite explain. The plan is not overhead. It is the thing that lets a small team move like a larger one, and it is the backbone of any spec-driven AI deployment.

What we do, and why it comes before the budget

This is exactly the work First AI Movers runs for European SMEs. Before a euro goes to tooling, we run a spec-driven planning and readiness assessment: we sit with you, find the one workflow worth automating, define the measurable outcome, confirm the data is reachable, set the guardrails, and agree the success and kill criteria. You leave with a map, the small-company version of that winning PRD, and a clear, bounded first project instead of an open-ended experiment. It is an AI readiness assessment small business teams can actually act on.

The reader is the hero here; we are the guide that holds the pen on the spec so your team does not start typing into an AI tool with no destination.

Frequently Asked Questions

Why do most AI pilots in small companies fail?

In the large majority of cases, the technology is not the problem, modern models are more than capable of the operational workflows SMEs need. Pilots fail upstream: no written spec, no measurable outcome, no scope boundary, and no agreed point at which to stop. The team starts prompting and the project drifts until it is quietly abandoned. The fix is to map the project before building any of it.

How long should AI project planning take for an SME?

Far less than the build. The minimum viable AI spec, one workflow, one measurable outcome, the data needed, the guardrails, and success/kill criteria, is usually a focused session or two, not weeks. The Tekton team wrote their whole plan inside a 12-hour hackathon. The goal is not a perfect document; it is a clear, agreed boundary before you spend.

What is the difference between a spec and just describing what we want?

We want better customer support is a wish. A spec names the single workflow, attaches a number that proves success, lists the data the AI must see, sets what it must never do, and states the result at which you scale or stop. The difference is testability: a spec can be judged true or false; a description cannot, which is why descriptions lead to abandoned pilots.

Does spec-driven planning slow down getting AI live?

No, it usually speeds it up. Planning first is what let the hackathon winners run independent workflows in parallel safely. For an SME, a clear map turns one vague project into a few independent, parallelisable steps, so a small team can move faster and avoid the rework that comes from building without a destination.

Further Reading

• Five AI use cases that pay for themselves in ninety days
• An honest guide to AI adoption fears for European SME leaders
• The AI developer's definition of done
• What three hackathon winners teach small companies about AI

We Write the Spec Before You Spend the Budget

If your last AI experiment did a bit of everything badly, the missing piece was almost certainly the map. Start with our AI Readiness Assessment to find the one workflow worth automating and define what success looks like before you commit a euro to tooling. When you are ready to build on that foundation, our AI consulting turns the spec into a bounded, working deployment, not an expensive toy.

Follow First AI Movers on LinkedIn for practical AI frameworks and decision guides.

TL;DR: OpenAI sunsets the Assistants API in August 2026: move to the Responses API, with MCP as the tool-connector standard. What leaders must do first.

The Model Context Protocol (MCP) is now the default standard for connecting AI agents to external tools and data. OpenAI is retiring its proprietary Assistants API in favour of the Responses API (with MCP, now the default tool-connector standard, native to it), and in December 2025 Anthropic donated MCP to the Linux Foundation's new Agentic AI Foundation, co-founded with Block and OpenAI and supported by Google, Microsoft, AWS, Cloudflare, and Bloomberg (S3). If you built anything on the Assistants API, migration is now mandatory. If you have not yet picked an agent integration standard, the decision has effectively been made for you.

This is not a gradual transition. OpenAI announced the OpenAI Assistants API sunset on August 26, 2025: the beta is deprecated now, and the endpoints stop working on August 26, 2026 (S4). Every integration, custom tool, and workflow built on that API has to move to the Responses API (and the Conversations API for conversation state) before then, adopting MCP for its external tool connections. For European SMEs running AI agents in production, this is the most important infrastructure decision to close out before the August 2026 deadline.

The OpenAI Assistants API Sunset and How MCP Became the Standard

• November 2024, Anthropic releases MCP as an open-source protocol for connecting AI models to external tools, launching on November 25, 2024 with Python and TypeScript SDKs under the MIT licence (S1).
• March 2025, OpenAI adopts MCP, adding support across the Agents SDK, the Responses API, and ChatGPT desktop from March 26, 2025 (S2).
• December 2025, Anthropic donates MCP to the Agentic AI Foundation under the Linux Foundation on December 9, 2025; the foundation is co-founded by Anthropic, Block, and OpenAI, with Google and Microsoft among its supporters (S3).
• Early 2026, OpenAI deprecates the Assistants API in favour of the Responses API, which is MCP-native (S4).
• 2026, Well over 1,000 community MCP servers are listed in the official registry (S5), and Claude Code, Codex CLI, and Gemini CLI all support MCP.

Why MCP Won

What MCP Actually Does

MCP defines how an AI agent discovers, connects to, and uses external capabilities. Tools become services rather than inline function definitions. An MCP server that searches your database works with Claude Code, Codex CLI, Gemini CLI, and any other agent that speaks MCP.

from mcp.server import MCPServer

mcp = MCPServer("file-search")

@mcp.tool()
def search_files(query: str, directory: str) -> list:
    return find_matching_files(query, directory)

mcp.run()

Any MCP-compatible agent connects to this server and calls the tool without knowing how it works internally. Build once, run everywhere.

Model Context Protocol Migration Guide: Adopting MCP

How to Choose

• Simple tool calling for a single model, the Responses API migration path is the lightest (S4).
• Reusable tools across multiple models, MCP servers.
• Team-shared capabilities such as database, deploy, and monitoring, MCP servers.

The MCP Ecosystem

Reference MCP servers, for filesystem access, GitHub, and more, are maintained in the official Model Context Protocol servers repository (S6), and the community registry lists well over 1,000 more (S5).

What to Do Now

This Week

• Audit every Assistants API integration.
• Confirm the sunset date for your plan tier.
• Decide whether you need the Responses API (single model) or MCP (cross-model).

This Month

• Build one MCP server for your most-used tool.
• Connect it to your primary agent, such as Claude Code or Codex.
• Document the pattern for your team.

Before August 2026

• Migrate all Assistants API integrations.
• Test in staging.
• Update your agent documentation with the new MCP servers.

Frequently Asked Questions

Is MCP the same as function calling?

No. Function calling is how a model requests tool execution within a single API call. MCP is a protocol for connecting models to persistent tool servers across calls and across models.

Do I need to migrate if I only use ChatGPT?

If you only use the web interface, no. If you call the Assistants API programmatically, yes, those endpoints are being retired (S4).

Can MCP servers run on my own infrastructure?

Yes. MCP servers are ordinary programs that run anywhere, a laptop, a server, a container, or your cloud. No data leaves your network unless the server logic sends it.

How does MCP relate to agent-to-agent protocols?

MCP connects an agent to its tools. Agent-to-agent protocols handle communication between separate agents. They are complementary, not competing.

Further Reading

• Every AI coding agent CLI in April 2026, compared
• A lower-cost Claude Code alternative built on OpenCode and MiniMax
• Solo developer versus enterprise: AI agent adoption realities

The Standard Is Settled

MCP is now the default AI agent protocol standard: backed by every major AI company, governed by the Linux Foundation, and supported by every serious coding-agent CLI (S3). The OpenAI Assistants API sunset is a hard deadline, not a suggestion.

If your team needs help planning the Model Context Protocol migration or building MCP servers for your internal tools, start with an AI Readiness Assessment or explore AI Consulting.

Follow First AI Movers on LinkedIn for practical AI frameworks and decision guides.

The term was named by Mitchell Hashimoto, co-founder of HashiCorp, in a February 2026 essay (S1), then formalized by Birgitta Böckeler, a Distinguished Engineer at Thoughtworks, in her guides and sensors framework on Martin Fowler's site (S2). Thoughtworks' own Technology Radar Vol. 34 now urges teams to wrap coding agents in exactly these feedforward and feedback controls (S3). The shorthand that captures it: Agent = Model + Harness. The model writes code. The harness makes sure that code is safe, compliant, tested, reviewed, and fit for your specific business context before it reaches production.

If you run a bank, an insurance company, a healthcare provider, an e-commerce platform, or any regulated European business, this is not optional. It is the architecture that lets you say yes to AI coding agents without saying yes to uncontrolled risk.

TL;DR: Harness engineering wraps an AI coding agent in guides (CLAUDE.md, AGENTS.md) and sensors (tests, linters, security scans, PR review) so its output stays safe, compliant, and auditable before production.

What a Harness Actually Is

A harness is everything around the AI model that controls its behaviour:

┌─────────────────────────────────────────────────────┐
│                    THE HARNESS                       │
│                                                      │
│  ┌──────────────┐     ┌──────────────────────────┐  │
│  │   GUIDES     │     │       SENSORS            │  │
│  │ (feedforward) │     │     (feedback)           │  │
│  │              │     │                          │  │
│  │ CLAUDE.md    │     │ Tests (pass/fail)        │  │
│  │ AGENTS.md    │     │ Lint (ruff, eslint)      │  │
│  │ System prompt│     │ Type check (mypy, tsc)   │  │
│  │ Tool limits  │     │ Security scan (Snyk)     │  │
│  │ File scope   │     │ PR review (Codex, human) │  │
│  │ Branch rules │     │ Post-merge monitoring    │  │
│  └──────┬───────┘     └──────────┬───────────────┘  │
│         │                        │                   │
│         ▼                        ▼                   │
│  ┌──────────────────────────────────────────────┐   │
│  │              AI MODEL                         │   │
│  │     (Claude, GPT, DeepSeek, Gemini)          │   │
│  │                                               │   │
│  │  Writes code within the constraints above     │   │
│  └──────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────┘

Guides (Feedforward Controls)

Guides constrain the agent before it acts. They define what the agent knows, what it can do, and what it must not do.

Sensors (Feedback Controls)

Sensors observe after the agent acts and either block bad output or feed corrections back.

Why You Need Both

Feedforward-only (guides without sensors) encodes rules the agent might ignore. You have a CLAUDE.md that says to write tests, but no CI check that verifies tests exist.

Feedback-only (sensors without guides) catches problems after they happen. The agent writes a large batch of code, CI fails on a long list of issues, the agent rewrites, CI fails on a different set. Expensive iteration.

The combination is what works: your CLAUDE.md AGENTS.md governance prevents most issues before they happen; sensors catch what guides miss.

The Harness Stack: AI Code Review Governance for a Regulated Industry

Different sectors need different sensors, but the shape is the same: these are the code quality gates regulated industry teams must be ready to show a regulator, and the AI code review governance that makes every AI-generated change attributable.

Banking and Financial Services

Insurance and Healthcare

E-Commerce

Building Your Harness: The Practical Steps

Step 1: Write Your CLAUDE.md (30 Minutes)

This is the single most impactful step. Every AI coding session starts by reading this file.

# CLAUDE.md

## What this project is
[1-2 sentences describing the business context]

## Technology stack
- Language: Python 3.11 / TypeScript 5.x
- Framework: [your framework]
- Database: [your database]
- Tests: pytest / jest in [directory]

## Rules (mandatory)
- Write tests for every new function
- Never modify files in config/production/
- Never hardcode secrets, use environment variables
- All database queries must use parameterised statements
- No PII in log statements

## Review standards
- Missing tests = P1 (blocks merge)
- New external API without rate limiting = P1
- Security scan failure = highest severity (blocks everything)

Step 2: Set Up Automated PR Quality Gates (1 Hour)

# .github/workflows/quality-gates.yml
name: Quality Gates
on: [pull_request]

jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: pytest
      - name: Lint
        run: ruff check .
      - name: Type check
        run: mypy src/
      - name: Security scan
        run: semgrep scan .
      - name: Test count guard (floor = 100)
        run: |
          COUNT=$(grep -rhoE 'def test_' tests | wc -l)
          test "$COUNT" -ge 100

Step 3: Enable AI PR Review (5 Minutes)

Enable Codex code review in your Codex settings (turn on Code review and, separately, Automatic reviews), and add review guidelines to AGENTS.md. Every new PR then gets an automatic AI review before human review.

Step 4: Configure Branch Protection (10 Minutes)

GitHub → Settings → Branches → Branch protection rules:

• Require pull request reviews (minimum 1)
• Require status checks to pass (tests, lint, security)
• Require branches to be up to date
• No force pushes
• No deletions

Step 5: Add Post-Merge Monitoring (Optional, 2 Hours)

For production deployments: alert on error rate spikes, latency increases, or conversion drops within 1 hour of merge. Automated rollback if thresholds are exceeded.

What We Built (Our Own Harness)

We practice what we publish. Our content engine's harness includes:

• CLAUDE.md, a detailed set of project conventions, plus a lane state guard and a source count check
• AGENTS.md, review guidelines, an autonomy envelope (MAY/HALT/PROHIBITED actions), and content quality and trust standards
• Pre-commit hooks, a lane state guard (prevents wrong-branch commits) and a source count check (validates article citations)
• Thousands of automated tests behind a hard CI floor; we never merge if the count drops
• Codex review-thread gate, a read-only CI gate that enumerates unresolved AI-reviewer threads on every PR before merge. It has no GitHub App and runs no model-harness CLI, so it surfaces review threads rather than measuring code correctness itself
• Tenant isolation, multi-tenant architecture with per-tenant runtime paths, no cross-contamination
• Distribution ledger, append-only record of every publish action

This harness is why we can operate two active tenants (with further tenants configured), publish autonomously, and maintain quality. The model writes. The harness governs.

The Cost of Not Having a Harness

Each of these is the kind of failure that is expensive and reputation-damaging once it reaches production: a breach notification, an emergency credential rotation, a revenue-affecting bug. The harness costs about 2 hours to set up.

Frequently Asked Questions

Do I need a harness if my team only has 3 developers?

Yes, even more so. With 3 developers, every person's time is precious. A harness prevents the 2-day debugging session caused by a bad AI-generated merge. The 2 hours of setup saves 20+ hours of incident response per year.

Is CLAUDE.md the same as AGENTS.md?

CLAUDE.md is project-level context (technology stack, conventions, file structure). AGENTS.md is team-level governance (review standards, autonomy boundaries, brand rules). Both are guides in the harness, but they serve different purposes.

Can I use this with any AI coding agent?

Yes. The harness is model-agnostic. CLAUDE.md works with Claude Code. AGENTS.md works with Codex. CI quality gates work with any agent that commits code. Branch protection works regardless of who creates the PR.

How do regulated industries (banks, insurance) audit AI-generated code?

Through the harness's audit trail: git commit history (who/what generated the code), CI logs (which checks passed), PR review history (what was flagged and resolved), and AGENTS.md versioning (what rules were in effect when the code was written).

What is the difference between harness engineering and DevOps?

DevOps automates the build, test, and deploy pipeline. Harness engineering adds a governance layer specifically for AI agents: constraining what they can do (guides), verifying what they did (sensors), and maintaining auditability. Think of it as DevOps + AI governance.

Further Reading

• AI Developer Definition of Done: When Agent Code Is Ship-Ready
• Codex GitHub Connector: Automated PR Reviews That Work
• Worktree Isolation: Safe Parallel AI Agent Sessions
• Shadow AI Agents: The Governance Gap Your Team Has Now
• EU AI Act: What European SMEs Must Do Before August 2026

We Build Harnesses

If your organisation needs AI coding agents governed to your standards, whether you are a bank that needs SOX compliance, an insurance company under Solvency II, a healthcare provider under HIPAA, or an e-commerce platform protecting revenue, we build the harness.

We do not sell the AI model. We build the governance around it: CLAUDE.md, AGENTS.md, CI quality gates, PR review automation, branch protection, post-merge monitoring, and the audit trail that lets you explain to a regulator exactly how AI-generated code reaches your production environment. This is the AI agent harness enterprise buyers can put in front of an auditor.

Start with an AI Readiness Assessment to evaluate your current governance posture. Or talk to us about building a harness for your specific compliance requirements.

The model writes the code. The harness makes it safe. We build the harness.

Follow First AI Movers on LinkedIn for practical AI frameworks and decision guides.

TL;DR: First AI Movers builds custom AI platforms, SaaS products, and automation systems for European SMEs, from idea to production on any cloud or model, with no vendor lock-in.

You do not need a large in-house engineering department to build an AI-powered product. You do not need to hire a CTO who understands both your business and the AI landscape. You do not need to choose between a generic SaaS that almost fits and a custom build that drags on for a year and a half. You need a team that has built autonomous AI systems in production, understands European compliance, and can turn your description into a working product, on any cloud, with any model, on your timeline.

That is what First AI Movers does. We are not a consulting firm that writes reports. We are the engineering team that builds the system the report recommends.

What We Build: Custom AI Platform Development

Custom AI Platforms

This is custom AI platform development European businesses can trust: full-stack AI applications tailored to your business. Not a wrapper around ChatGPT, a purpose-built system with your data, your workflows, your compliance requirements.

Examples from our portfolio:

• Autonomous content engines, signal-driven topic selection, multi-model content generation, multi-surface publishing, performance tracking, self-improvement loops. Our own engine publishes at scale behind thousands of automated tests.
• Multi-tenant SaaS platforms, isolated tenants, configurable publishing surfaces, per-tenant analytics, role-based access. We run multiple tenants on one substrate.
• Grant and tender intelligence systems, EU funding databases, automated relevance scoring, deadline tracking, application support content generation.

SaaS Products

Want to build AI SaaS European company founders can scale on? From idea to production, we handle architecture, development, deployment, and ongoing operations.

What we deliver:

• Working MVP in 4-8 weeks (not many months)
• EU-hosted infrastructure (Hetzner, AWS EU, Azure EU, GCP EU, your choice)
• GDPR-compliant by design, not as an afterthought
• EU AI Act awareness built into every AI component
• Multi-language support (EN, NL, DE, PT, FR, ES)

Automation Systems

AI automation services SME teams actually adopt: replace manual workflows with intelligent automation. We connect your existing tools (CRM, ERP, CMS, email, Slack) with AI that understands your business context.

What we automate:

• Content generation and distribution pipelines
• Customer communication (email sequences, chatbots, support triage)
• Data processing and reporting
• Document analysis and extraction
• Vendor evaluation and procurement support

How We Work

Step 1: You Describe It

Tell us what you want to build. A product idea, a workflow problem, a competitive advantage you need. You do not need technical specifications, you need a clear description of the business outcome.

Step 2: We Design the Architecture

Within one week, you receive:

• A system architecture document with component diagrams
• A technology selection rationale (why this model, this database, this hosting)
• A compliance assessment (GDPR, EU AI Act applicability)
• A cost estimate (development + monthly operating)
• A timeline with milestones

Step 3: We Build in Sprints

2-week sprints with working deliverables at each milestone. You see progress, provide feedback, and steer direction. No disappearing for 6 months.

Step 4: We Deploy and Operate

Your choice of deployment:

• Sovereign, on your own infrastructure, you own everything
• Managed, we deploy and operate it for you on EU-hosted cloud
• Hybrid, you own the infrastructure, we manage the application

Step 5: We Stay or We Leave

After deployment:

• Handoff, full documentation, knowledge transfer, your team takes over
• Retainer, ongoing maintenance, updates, monitoring (Fractional CAIO model)
• Growth, continued feature development as your needs evolve

Why European SMEs Choose Our Fractional AI Engineering Team

We Are Not a Body Shop

Unlike the typical AI development team for hire Europe is used to, we do not rent developers by the hour and hope for the best. We are an engineering team that has built and operates production AI systems. Our own content engine runs autonomously with a large automated test suite, multi-tenant isolation, and multiple signal sources. We apply the same engineering discipline to your project.

We Understand European Compliance

The EU AI Act is not a future concern, it is an active regime whose obligations are phasing in through 2026 and 2027. Every system we build includes:

• Risk classification against EU AI Act Annex III
• Human oversight design where required
• Data residency on EU soil
• GDPR-compliant data handling
• Documentation trail for regulatory audit

We Are Cloud-Agnostic

No vendor lock-in. We deploy on:

• Hetzner (EU-based, cost-effective, sovereign)
• AWS (EU regions, Ireland and Frankfurt)
• Azure (West Europe, North Europe)
• Google Cloud (EU regions, Belgium and the Netherlands)
• Your own infrastructure (on-premise, Coolify, Docker)

The architecture is portable, the same substrate that runs sovereign AI applications EU regulators expect. If you want to move clouds later, you can.

We Work with Any AI Model

No model lock-in. We integrate:

• Anthropic (Claude Opus, Sonnet, Haiku)
• OpenAI (GPT-5, GPT-4o)
• Open-source (DeepSeek, Gemma, Llama, Qwen)
• Self-hosted (Ollama, vLLM, TGI)

The right model for each task. Planning requires reasoning depth (Opus). Fast execution uses cheaper models (Sonnet, DeepSeek). We route intelligently, you pay for quality where it matters and speed where it does not.

What It Costs

Transparent pricing. No surprises.

Compare: a single senior AI engineer is a six-figure annual cost once you add benefits and management overhead. Our MVP engagement delivers a working product for a fraction of that, and you get a team, not a person.

The Technology Stack

We build with production-tested tools:

Generative Engine Optimization: Built Into Everything We Publish

Every piece of content we create, for ourselves and for clients, is optimised for three search paradigms simultaneously:

Google AI Overviews now appear across a large and growing share of searches, and content that is well structured for machines is markedly more likely to be cited in AI-generated answers. Independent research from Princeton and collaborators, GEO: Generative Engine Optimization, found that optimising content for generative engines can lift its visibility in AI answers by up to 40% (S1).

We do not just write about GEO, we practice it. Our content engine has SEO and AEO validation built into the publish pipeline. Every article passes through quality gates that verify meta titles, FAQ sections, internal linking, and schema markup before it goes live.

Frequently Asked Questions

Can you build an AI product if I only have a business idea, not technical specs?

Yes. That is the most common starting point. You describe the business outcome you want. We translate it into architecture, select the right technologies, and build it. The Discovery + Architecture phase exists specifically for this.

How long does it take to get a working product?

MVP in 4-8 weeks. Full production platform in 3-6 months. We work in 2-week sprints with working deliverables at each milestone, you see progress from week 2, not month 6.

Do I own the code?

Yes. You own everything we build. Full source code, documentation, and deployment scripts are handed over. No proprietary frameworks, no lock-in, no you need us to run it traps.

What about the EU AI Act?

Every system we build includes an EU AI Act risk classification. If your AI use case falls under Annex III (high-risk), we design the required human oversight, logging, and documentation from day one, not as a retrofit.

Can you work with my existing engineering team?

Yes. We integrate as a fractional AI engineering team. Your developers participate in sprint reviews, learn the architecture, and can take over maintenance after handoff. We are not trying to replace your team, we are trying to accelerate it.

What if I already have a platform and need AI added to it?

That is a common engagement. We assess your existing architecture, identify where AI creates the most value, and integrate it without rebuilding what works. Typical: add an AI-powered search, automate a manual workflow, or add content generation capabilities.

Further Reading

• AI Readiness Assessment for European SMEs
• EU AI Act: What European SMEs Must Do Before August 2026
• We Built the Engine But Not the Chassis: AI Team Velocity
• The Agentic AI Adoption Framework European SMEs Need in 2026

Start With a Conversation

If you have an idea for an AI-powered product, a workflow that needs automation, or a platform that needs AI capabilities, start with a conversation.

Take our AI Readiness Assessment to understand where your organisation stands. Or go directly to AI Consulting to discuss your project.

We build what you describe. On any cloud. With any model. Under EU compliance. No vendor lock-in. No compromise.

Follow First AI Movers on LinkedIn for practical AI frameworks and decision guides.