Living Applications and Result Contracts

Up to now, much of the digital world has been organised around the idea of a relatively fixed application: specified, built, shipped, maintained, patched, and occasionally redesigned. Even when it evolves continuously, the conceptual centre of gravity often remains a codebase managed by humans through periodic intervention.

A new class of software may behave less like a finished artefact and more like an organism guided by a result contract authored by humans: what the system must achieve, what constraints it must respect, what quality threshold it must maintain, and within what boundaries it is authorised to act.

This does not abolish software engineering but it changes where software engineering places its centre of gravity.

#The result contract as operational origin

The result contract formalises intent at the level that actually counts: outcomes, constraints, authority, and evaluation. Instead of manually prescribing every small implementation path, the human defines what the application must continue to satisfy.

An agentic system can then scaffold, iterate, test, compare, revise, and publish toward that result, provided it has the required permissions, observability, and feedback channels. In that model, the application is not merely built and then occasionally serviced. It is continuously driven toward compliance with its contract.

This is one of the places where the agentic future most clearly escapes the idea of AI as only a conversational assistant. Here, agents become operational maintainers, builders, correctors, and evolving mediators inside the software itself.

#A concrete case: the invoice that must stay valid

Take a small invoicing tool used by French freelancers. Its contract fits in one sentence: every invoice it produces must be accepted by the state-certified platforms through which French invoices now have to transit. Since 1 September 2026, every company in France must be able to receive electronic invoices, and from 1 September 2027 small businesses and micro-entrepreneurs will have to issue them too, in structured or hybrid formats such as Factur-X. The tool's users are precisely the people who will discover the obligation late.

The rules will not stay still. The administration publishes clarifications, the format specifications get new versions, the platforms tighten their validation, and the tolerance period announced at launch will eventually end. In the classic model, someone on the team eventually notices that something changed, writes a ticket, and the fix ships with the next release. Between the change and the release, invoices get rejected, and the users find out first.

In the contract model, the agentic layer watches the sources that define validity: the official texts, the format specifications, the rejection messages coming back from the platforms. An invoice rejected for a reason the system has never seen is drift, a gap between the contract and reality. The agent traces it to the field or the rule concerned, checks which invoice flows are affected, writes the correction, runs it against the official validator and against every invoice template the users rely on, and opens the change for review. A human approves it, because the contract says that any change touching tax rules requires a human signature. The next invoice goes through.

Nothing in that loop is exotic. What is new is where it starts: not from a ticket someone wrote, but from the distance between what the system was supposed to guarantee and what it actually did.

Where this stands (autumn 2026)

Each piece of that loop exists. None of them is closed around a contract yet.

On the build side, since March 2026 a Jira issue can be assigned to GitHub Copilot's coding agent (in public preview): it reads the issue and its comments, asks clarifying questions in Jira when it needs to, and returns a draft pull request that goes through the team's existing review rules. On the operations side, Datadog's Bits AI SRE investigates incidents on its own, forming root-cause hypotheses and testing them against metrics, logs and traces. Automated remediation, such as a rollback or a feature-flag change, is possible within guardrails the customer defines, although Datadog itself recommends that in finance the agent proposes and the human decides.

What is missing is the step before the ticket. In both cases a human still decides that there is something to do. The agent executes the work; it does not yet derive it from a standing objective.

Sources: GitHub changelog, "GitHub Copilot coding agent for Jira is now in public preview", 5 March 2026; Datadog, DASH 2026 announcements (Bits AI SRE).

#Anatomy of a living application

What does the agent actually need for this? Less than it seems. Give it five things: the web application itself, an email address, an Elastic server, access to the GitHub repository, and the right to retrain the model at the core of the application. That is enough for the application to evolve on its own, under supervision, through three loops.

The first loop is technical, and it runs through Elastic. Every request, every error, every latency spike and every rejected invoice ends up in the logs. The agent reads them continuously, the way an on-call engineer would if they never slept. It notices that rejections from one platform jumped after a format update, that a page got slower after the last deployment, that one error only appears for users of a particular browser. Each anomaly becomes a hypothesis, and each confirmed hypothesis becomes an issue in the repository.

The second loop runs through the users, by GitHub issues and above all by email. A few users open issues. Most of them simply write to the support address, in their own words, often annoyed, rarely precise. The agent answers, asks the question that was missing, and turns the email into a structured issue: what the user tried, what happened, which invoice. Requests that are really the same complaint get merged, so that a feature asked for by forty freelancers in forty different phrasings becomes one issue with forty voices behind it.

Both loops end in the same place: an issue, then a branch, a fix, tests, a pull request, and a deployment when the contract allows it. Elastic then shows whether the fix actually worked, which closes the loop.

The third loop goes deeper. The tool relies on a model to read what a freelancer actually does and decide which VAT regime applies and which mentions the invoice must carry. Every time a user corrects one of those choices, by email or directly in the interface, the correction is training data. Once enough of them have accumulated, the agent retrains the model, evaluates the new version against a held-out set of verified invoices, and proposes it for production only if it does better without breaking what already worked. The application then changes not only its code but the way it understands its own domain. At that point the model is no longer a commodity plugged in from outside; it has become part of the business logic itself. And it is the one part a competitor cannot copy by reading the code: as with presences in the first part, a skill can be downloaded, weights cannot.

Here again, the contract sets the limits: which changes can ship on their own, which ones need a human signature, and which version of the model is allowed to reach production.

That is why the older vocabulary of the “self-healing app” is too narrow. The point is not merely that software repairs itself after breakage. The point is that it can be continuously scaffolded, corrected, reoriented, and advanced toward a human-authored objective.

#The future of software as supervised adaptation

What emerges from all this is a different image of software as a supervised adaptive process moving under constraint toward results defined by humans, much as AI models are "grown" today.

That may become one of the deepest consequences of the agentic transition. The application is continuously maintained, corrected, and developed by agentic processes under governance.

Who writes that contract remains open: a company, a team, or, as the next chapter suggests, the holders of a token.