The Aiske.ai app is, at its heart, a collection of workflows: record a treatment, register a calf, log a weight, file a movement — then report on it all. Those workflows are the product, and rewriting them all at once would be reckless. The Strangler Fig pattern lets us do something safer and faster instead: grow the new system around the old one and let it take over gradually.
It's named after the strangler fig — a vine that germinates in the canopy of a host tree, sends roots down around its trunk, and slowly envelops it. The host keeps the whole thing standing for years while the fig grows; eventually the fig is self-supporting and the original tree is gone. Martin Fowler borrowed the image in 2004 to describe a way of modernising legacy software without rewriting it in one move.
The mechanics are simple. You put a façade in front of the existing system. New functionality is built as independent modules behind that façade. The façade routes each request either to the new module or to the old code. One capability at a time, traffic shifts to the new system — and when nothing depends on a piece of the old code any more, you delete it. Value ships continuously, and the catastrophic risk of a "big rewrite that launches in 18 months" disappears.
A big-bang rewrite of a live, revenue-generating app means months with nothing to show, a giant cut-over, and a single point of catastrophic failure. The fig delivers working value from the first workflow and never has a "launch day".
Each workflow migrates independently and can be feature-flagged on for a few farms first. If one isn't right, you roll back that one workflow — not the whole app. Risk is spread across dozens of small, reversible steps.
We can ship brand-new, web-delivered features in hours, yet features inside the app can take months. That gap isn't an effort problem — it's architectural. Greenfield work is fast; a coupled, years-old mobile codebase carries a great deal of implicit business logic that resists change, and it's tied to the native build-and-store release cadence on top. AI made that contrast impossible to ignore.
The Strangler Fig is the deliberate response. Rather than "use AI harder on the monolith" (which has a real ceiling), we build each new capability outside the old code and route to it — and over time we re-home the existing workflows the same way. The app we already have keeps the whole thing standing while the new system grows.
The façade in our case is A2UI — an agent-to-UI protocol. Instead of every screen being hand-built native code, Aiske's backend describes a workflow as structured surfaces (a form, a confirmation card, a column-mapping table) and the app renders them from a shared component catalogue. The conversation becomes the router: a farmer asks for something, Aiske decides which workflow applies and streams back the surfaces to render.
That's what turns "replace the app gradually" from theory into something practical. Once the component catalogue is rich enough, a new workflow is mostly a backend definition — it can ship without a native release and without an app-store wait, which is exactly why our out-of-app work is so fast today. See the A2UI protocol page → for how the surfaces and actions are defined, and the Aiske architecture explorer → for where the Workflow node and Workflow store sit in the graph.
The value compounds only if the surfaces layer, the component catalogue and the write-workflow pattern (validate → preview → confirm → commit) are built generically, not per-feature. Get that right and workflow #2 through #N become cheap. That's the difference between the fig taking over and a one-off feature with extra plumbing.
The migration runs in three overlapping phases. The read-and-report half is mature and proven; the write half — actually recording farm data through Aiske — is the genuine new ground, and we're building it one workflow at a time starting with weight upload.
Natural-language answers over your farm data.
The first workflows that change farm data, delivered via A2UI.
Every new workflow ships A2UI-first; existing screens move across.
First instance in flight: Aiske 1.5 Weight Upload MVP (FARM-12136) — chosen as the template because it's a self-contained, online-only workflow that exercises the full write path. Its real cost (the validate/confirm/commit machinery, not the UI) is our leading indicator for how quickly the rest can follow.
Illustrative — the share of workflows delivered natively vs through Aiske/A2UI as the fig grows. The read/report layer is already Aiske; write workflows cross over phase by phase.
A2UI workflows are online: Aiske has to be reachable to drive the surfaces. But much of rural Ireland and the UK has poor signal in the field, and our offline recording is a genuine reason farmers choose us. So the core in-field capture stays native and offline-first. The fig takes over the online workflows, the analytics and the net-new modules; it does not strangle the part of the app that works with no signal. That's a deliberate boundary, not a gap.
Once the catalogue is built, a new workflow is largely a backend definition — no native release, no app-store wait. The same reason our out-of-app work ships in hours.
We modernise the revenue-generating app one reversible step at a time, behind feature flags, instead of betting the product on a single cut-over.
Every workflow we move makes the catalogue richer, so the next one is cheaper. The platform — not any single feature — is what we're really building.
Farmers increasingly do things by asking Aiske in plain language. Record, report and analyse converge on a single conversational surface across mobile and web.
Sources: Aiske architecture (de-svc-herdchat) and app (ngx-app · libs/ai-chat); Jira epic FARM-12136 (Aiske 1.5 Weight Upload MVP) and child stories; A2UI protocol reference. Pattern origin: Martin Fowler, "StranglerFigApplication" (2004). The mix chart is illustrative.