API days · 2026
Contracts earn trust.
How contracts, stubs, and pipelines can decouple distributed teams working at different cadences - and why that discipline is exactly what AI needs.
Mike Holdsworth · monowai.com · Singapore
the thesis
AI amplifies the architecture it finds
Agents
probabilistic - proposes
Plain-English access, generated queries, generated apps - reasoning over the ontology, not the codebase.
monday morning
Start with one microcontext: an agent scoped to your standards and contracts - never the codebase. No catalogue? Don't start here.
↑ makes agents safe to accelerate
Automation
deterministic - verifies
Contracts run as stubs; the pipeline checks every change; a breaking change fails before merge.
monday morning
Wire one pipeline: lint, verify compatibility, publish a stub. A day's work with today's tooling.
↑ makes agreements real
Agreements
shared meaning
Ownership and ontology settled at the seams - what a Client is, where the boundaries fall - versioned like code.
monday morning
Pick one troublesome producer-consumer pair. Agree the contract and its examples this week.
↑ built on
Engineering practice
well established - the bedrock
Version control · continuous delivery · automated testing · code review - a decade of DORA evidence behind every layer above.
already yours
No new tools, no new methodology - the stack aims the practices you already trust at the seams between teams.
Discipline compounds. Confusion accelerates. Each layer makes the one above it safe to speed up.
the talk in one slide
Ownership, agreed and automated
the problem
Loosely agreed ownership and responsibility, split across teams - misaligned expectations and poor delivery outcomes.
what we did
Ownership agreed where it breaks - at the contract - then automated with effective workflows that hold every team to it.
the outcome
Expectations made executable - teams decoupled, quality deliverables you can predict.
The federated estate - everything is integration
Federation multiplies the seams
multiple domains × multiple markets × every app
Every line is an agreement between two teams - if you simply program it, you'll find it lives in a wiki page and a few programmers' heads.
If nothing enforces the seams, then nothing protects them - and each one will present its bill.
the cost - paid on every deadline
The integration tax
Roadmaps held hostage
Teams don't move in step - yet integration forces them to. Every plan waits on someone else's deploy.
Breakage at the seams
Each service tests well in isolation. The failures live between services - and surface last, where they're most expensive.
Manual QA absorbs it
A large, manual QA phase becomes a load-bearing workaround for an unowned integration layer.
The QA bottleneck isn't a people problem - it's structural: nobody owns the space between the services.
the premise - contract-first design
The contract is the agreement
Producer and consumer agree the contract. Not the framework, not the language, not the vendor.
Design and documentation are mastered in the contract - an OpenAPI spec agreed before a line of service code exists. The design arguments, the domain taxonomy included, are settled here - not in code review. That makes it the one artefact every team can share, whatever they build with.
the contract
OpenAPI spec · examples · versioned
One contract, any stack - producers and consumers choose independently.
discovery - before any tooling
How we drew the boundaries
The compliance surface
Not the org chart, not the technology, not who happened to own which system. Each domain owns its own regulatory position - a boundary that outlives both.
Taxonomy settled once
What is a Client, consistently, across six markets? What do we mean by a Document? Those arguments were had once, at design time.
Specs before service code
The domain model was argued, tyres kicked, and agreed before a line of service code existed. It looked slow. Highest leverage work we did.
Design isn't a phase you schedule - it's deciding what the words mean before you decide what the code does.
case study
Harmony - a federated integration layer
Apps
frontend clients - web, mobile, agent tools
↓
harmony
graph + domain services · consistent · reusable · contract-first
Graph
one coherent data model - a single door for every client
↓
Product
Client
Payment
Policy
Document
↓
regional integration
contract-first · local autonomy · no central bottlenecks
Singapore
Malaysia
India
Hong Kong
Vietnam
Thailand
↓
Systems of record
the estate underneath - vendor engines, ledgers, legacy cores
Every seam is a contract. We expected them to help with testing - they became something more.
scaling development - stub while you build
Decoupled, yet aligned
Graph
one coherent model, every client
↓
↓
↓
Product
live
Client
specmatic stub
Payment
specmatic stub
Live or stubbed - the graph composes them, and clients can't tell.
specmatic
contract verification · JUnit testing · stubbing
Agree the contract
Producer and consumers design the contract together, with example data.
Stand up the stub
The pipeline hands the contract to Specmatic, which serves it as a running stub - day one.
Build in parallel
Consumers integrate against the stub while the producer builds the real thing.
Swap, not integrate
The real service replaces the stub. Contract unchanged - the graph doesn't notice.
The contract owns the seam - and your test environment is a set of contracts, not a shared server. Every team moves at its own pace against the same truth.
scaling development - automation
The central contract pipeline
Push PR
OpenAPI spec + examples
Lint
style & naming rules enforced
Verify
specmatic checks backward compat, service level integration impact
Publish
immutable version tagged
Stub server
Deliver specmatic stubs as a Docker image
Every contract change runs the same gauntlet. A breaking change fails the build - before it can break a team.
central contract repo
The pipeline in production
one push · 3m 57s · a monorepo of contracts · matrix scoped to what changed
impact
Diff the monorepo: which APIs, which regional businesses are touched.
build + stub
Each impacted contract verified; stub server rebuilt and published.
compliance
Review changes against defined traits for standards compliance.
service tests
Tests run against the actual impacted services.
aggregate
Fan-in: one verdict for the whole push.
Contracts are code - branched, reviewed, built, published. Impact-scoped, so only what changed is re-verified.
the shift - test specs to trusted assets
Architectural assets that can't rot
central contract repo
The contracts
specs · examples · versioned
workflow: clone each service
(same branch)
run its specmatic JUnit tests
each service build clones the contracts - specmatic verifies that service
────────────────────────────────────────▶
same branch · same working copy · one truth
────────────────────────────────────────▶
the contract build clones the services - runs their specmatic tests
service repo
product-api
build: clone CCR → verify
service repo
client-api
build: clone CCR → verify
service repo
payment-api
build: clone CCR → verify
Started as a testing convenience. Became the assets teams trusted - contracts are executable documentation, and if the docs are wrong, the build fails.
ways of working
Everything is a pull request
PR opened
contract or code - same door for every change
Machines respond
lint, specmatic verify, regression vs stubs, AI feedback review
Humans decide
reviewers argue design and intent, not formatting
Merge = releasable
green pipeline is the definition of done
in the pipeline
MicroContext spec review on every PR
~2 min
first review comment on every contract PR
- a review I used to do by hand
The review, codified
- Naming standards and path conventions, applied consistently
- Cross-domain leakage - concepts that belong to another domain
- Design hints - promote new objects, don't grow the root object
- The "this API looks good" smell test - right first time
Not a gatekeeper - a feedback loop. Humans keep the judgement calls.
- "MicroContext": Mehdi Medjaoui, APIdays - a context-specific agent, scoped the way we scope microservices. This one's world is our standards and contracts - never the codebase.
adoption
No slides. Just running code.
To earn adoption we ran a development workshop: containers, scripts, and working pipelines - a clear, testable architectural style teams could take away and make their own.
1 week
most teams hit their objectives inside it
1 mandate
the contract must be fulfilled - everything else is the team's choice
All levels
greenfield teams and teams with APIs in place
“ Trust in engineering, isn't built with tools, diagrams, or documentation. It's earned - through collaboration, iteration, and follow-through. It grows from clarity: working code, meaningful tests, and automated workflows that hold up under pressure.”
- the architectural realisation Harmony left behind
the AI world - neurosymbolic AI
The agent proposes. The contract permits.
Probabilistic reasoning inside, logical constraints outside - that's neurosymbolic, in practice.
new word, same artefact - the ontology is the contract you've been publishing all along
Agent - probabilistic engine
Proposes
- Same prompt, different code each run
- Plausible is not the same as Correct
- Human review can't scale to AI speed
Ontology - your contract, formalised
Permits
- The contract is the ontology - the agreement between every producer and consumer, not one implementation
- Contract documentation feeds the agent - it reasons over the ontology, not the codebase
- The ontology is the long-lived asset - implementations evolve or are replaced, the contract endures
- Permission is binary - the proposal verifies against the contract, or it doesn't ship
Trust the artefact, not the author - human or agent.
- a framing echoed in Frank Coyle's talk "Why Agentic Systems Need Ontologies," AI Engineer World's Fair
the agentic economy
Contracts are the index to your organisation
deterministic
Contracts published
the documented contracts - versioned, examples attached - are the map of what your organisation's data can do
probabilistic
Ask in plain English
“get the client's name and addresses” - no API knowledge required
probabilistic
Agent emits the query
it reasons over the graph's SDL - documented from the contracts - and produces the exact query, ready to run
deterministic
Claude builds the app
the deterministic query + architectural guidelines in → a working UI out, verified by the pipeline
Probabilistic reasoning in the middle. Deterministic contracts at both ends.
- built and running: an AI query assistant over the federated graph. SDL in, query out, UI generated from the deterministic result.
the agentic economy - in practice
The hardest query language is now plain English
graphql query assistant - as built · powered by the contracts
Get the client's name and addresses
Askgenerated query
Thinking…
query($clientId: String!) {
clientProfile(clientId: $clientId) {
name
addresses { line1 city zipcode
country { name code } type }
} } $ curl -X POST https://graph… - ready to run, with docs & explanation
The objection, retired
"GraphQL is so hard" stopped being a reason. The agent absorbs the query language - the business asks, the graph answers.
The contracts do the work
The agent's only knowledge is the SDL, documented from the contracts. Good documentation became executable capability.
Not a GraphQL story
The pattern holds over any contract catalogue - SDL, OpenAPI, events. If it's documented, it's indexable.
the quiet part - where the time came from
Effective CD engineering is an accelerator
No one asked us to build the query generator or the spec review. Our practices freed the time - so we built them.
That's the dividend: automation removed the toil of repetitive manual work and regression firefighting, and the reclaimed capacity became the AI tooling. Things get done in the doing.
taking it home
Start small, expand on proof
One contract
Pick a single producer-consumer pair - preferably troublesome. Agree the contract, add examples, stand up the stub.
One pipeline
Lint + specmatic verify + stub server. A day's work with today's tooling.
Expand on proof
Every win de-risks and funds the next seam. Proof beats mandate - every time.
One seam, one week - and every contract you publish is infrastructure for the agentic economy.
Thanks.
Contracts earn trust and position you to move with certainty in a probabilistic world.
- mike@monowai.com
- tooling
- specmatic.io · openapis.org