Monowai

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

Initiative → Analysis → Integration Contracts → Test → Stubs → Deploy → e2e → Deliver

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

apps domain services markets

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

↓ Kotlin
↓ Go
↓ TypeScript
↓ Python
↓ Java
↓ .NET

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

1

Agree the contract

Producer and consumers design the contract together, with example data.

2

Stand up the stub

The pipeline hands the contract to Specmatic, which serves it as a running stub - day one.

3

Build in parallel

Consumers integrate against the stub while the producer builds the real thing.

4

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

changes 1m 14s

Diff the monorepo: which APIs, which regional businesses are touched.

build + stub

harmony-api 2m 12s
market-builds 26s
build-stubs 18s

Each impacted contract verified; stub server rebuilt and published.

compliance

ai-review 18s

Review changes against defined traits for standards compliance.

service tests

verify-jvm
verify-node

Tests run against the actual impacted services.

aggregate

build-results 18s

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

1

PR opened

contract or code - same door for every change

2

Machines respond

lint, specmatic verify, regression vs stubs, AI feedback review

3

Humans decide

reviewers argue design and intent, not formatting

4

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

Ask

generated query

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.

email
mike@monowai.com
tooling
specmatic.io · openapis.org