P Peak · AI Platform Engineering
The destination · Rungs 4 & 5

One governed layer where people and agents actually work together.

Most enterprises will not run one general-purpose agent from one vendor. They will run many specialised agents across many models, collaboration tools, data sources, and business systems. Without a shared operating layer, every new agent becomes another isolated application with its own permissions, memory, integrations, audit trail, and failure behaviour. This is the layer that stops that happening — and it is where the work on this site is heading.

Six maturity stages advance from fragmented experiments to a federated network, with evidence gates between each stage.
Read this first

What a north star is, and what it is not

What it means

  • A named destination, so a baseline engagement reads as the first move in a strategy rather than an isolated audit
  • A ladder you can locate yourself on, which makes the next rung self-evident instead of something we have to argue for
  • A catalogue that gives every engagement somewhere to put what it discovers — a repeated need becomes a named module rather than one-off custom work
  • A build-versus-buy conversation that improves with distance: a platform team can build a tool plane; a governed cross-vendor coordination fabric with a lifecycle and an evidence model is a different proposition

What it does not mean

  • A promise of delivery scope. Every proposal names the rung it covers and the rungs it does not
  • A roadmap with dates. There are no dates on the ladder — rungs are states you reach, not quarters
  • Permission for us to build components before somebody pays for the behaviour
  • A reason to widen a statement of work. The destination changes the narrative, never the scope

Our operating rule, written down so you can hold us to it: publish the ladder, sell one rung, deliver that rung completely.

The honest position on capability. Rungs 1–3 are ours to deliver today. Rungs 4 and 5 describe the destination, and would be delivered with partners or a larger team when a client is genuinely ready for them. The path is real. Present capability is rungs 1–3. If anyone on our side ever implies otherwise, that is a mistake and we would want to know.

— Stated on the website rather than discovered in month four
The idea

Two kinds of communication, and a router between them

The design insight the rest of the architecture hangs from: agent coordination and human collaboration are different problems, and the failure mode of merging them is drowning everyone in machine chatter until they stop reading it.

Private programmatic coordination

Agents discover capabilities, delegate tasks, exchange structured results, use tools, retry work, and manage long-running execution — without exposing every intermediate step to people. Routine machine coordination stays private, because it is not news.

Open company collaboration

Material findings, decisions, disagreements, policy exceptions, approvals, incidents, and cross-team consequences get promoted into visible spaces — Teams, Slack, email, or a portal — where people and authorised agents participate.

private work → relevance / risk decision → shared context → human or policy decision → authorized execution

The Communication Router decides which is which, using policy plus deterministic metadata: business impact, data sensitivity, evidence quality, agent disagreement, novelty, cross-team relevance, requested authority, reversibility, cost and time thresholds, legal and contractual rules, and channel preference. Its actions range from keep private through summarise, create a case, request structured approval, to suspend or terminate execution. Routing decisions and their policy versions are auditable.

One rule is load-bearing: the router uses rules for authority and risk. Models may assist with classification or summarisation, but they cannot silently grant permission. Information becomes visible when it changes what people need to know, decide, approve, or own — not when an agent feels chatty. We have adopted this as a design principle in current delivery already, long before anyone builds the router itself.

Architecture

What the platform is made of — and how much of it already exists

Most of the mandatory core is capability we build at rungs 1–3, under different names and at a smaller scope. That is why the destination is additive rather than a separate product bet — and it is also why the gaps are worth naming precisely.

Platform capabilityWhat it doesRelationship to rungs 1–3
Identity, tenancy, trustWho an agent is, whose authority it carries, which boundary it sits insideSame capability, multi-tenant scope added
Agent, tool & workflow registryCompany-wide catalogue of approved agents, tools, workflows, owners, and permissionsThe context graph and tool contracts, given lifecycle and commercial metadata
Protocol & integration gatewayCross-vendor, cross-runtime interoperability between agents and systemsExtends tool contracts to agent-to-agent interoperability
Communication RouterDecides what stays private and what becomes visible, on policyGenuinely new — adopted now as a principle, built at rung 4
Durable task & workflow serviceExecution that survives process and network failure; a canonical task recordExecution memory formalised into a workflow engine
Policy, approval & action gatewayOne enforcement path for every consequential actionSame controls, consolidated
Audit, observability, quality, costEvidence, tracing, evaluation, and cost attribution across workflowsThe outcome ledger, extended across teams
Administration & lifecycleModule releases, entitlements, versioning, deprecationLifecycle control extended to modules
Knowledge & memory planeDurable organisational memory available to agents under policyContext graph plus data contracts — and we insist on the contracts half

A correction we apply to our own architecture. Coordination platforms tend to treat data as retrieval and memory, and quietly drop contracts, freshness, and quality gates on agent-touched datasets. We treat that as a standing defect: every module derived from this architecture is checked against the data-contract requirement before it ships. Why that matters →

— Published because it is the kind of thing that gets lost
The first proof

A lighthouse workflow: agentic incident and change coordination

If you want to know what rung 4 actually looks like in practice rather than in the abstract, this is the workflow we would prove it with. It is cross-functional enough to exercise both human-agent and agent-agent communication, and it has clear states, owners, time pressure, and escalation paths.

Incident evidence moves through specialist workstreams to a human decision, bounded execution, verification, rollback, and an evidence ledger.
  • Step 1

    An incident or high-risk change is created

    In your existing ITSM or engineering system. Nothing moves into a new collaboration product.

  • Step 2

    A durable task starts and the accountable owner is identified

    Execution that survives a process restart, with a canonical record of what is happening and who owns it.

  • Step 3

    Specialised agents collect evidence privately

    Observability, service ownership, deployment, security, and dependency agents work in the private layer. Nobody is paged for intermediate steps.

  • Step 4

    A concise, verified situation report is posted

    Into the approved Teams or Slack room. Verified — meaning postconditions and provenance were checked before it was promoted.

  • Step 5

    Disagreement, missing evidence, or a policy exception triggers a structured decision

    The router requests a human decision with the evidence attached, rather than proceeding on the most confident agent’s opinion.

  • Step 6

    An authorised person approves an exact bounded action

    A rollback, a traffic shift, evidence collection, or continuing a change window. Bounded and named, not open-ended authority.

  • Step 7

    The action gateway re-checks authority, executes, verifies, and records

    Authority is re-evaluated at the moment of action, not at the start of the session. The result is verified independently and the evidence is kept.

  • Step 8

    A review package proposes improvements

    To runbooks, alerts, evaluations, or the platform backlog. The loop closes into the estate rather than into a report nobody reads.

The same core later supports security operations, release readiness, compliance evidence, onboarding, and finance operations as further workflow packs. That is the point of a catalogue: the second workflow is a fraction of the cost of the first.

Autonomy

Nothing advances because a model sounds confident

Every workflow we deliver has a stated autonomy level and a written list of the evidence required to advance to the next one. Advancement is an accountable business and risk decision, supported by measurement.

LevelAgent authorityEvidence required to advance
0 — ObserveRead approved data and produce private evidenceAccess and provenance tests
1 — RecommendPropose an action; a person performs itQuality, usefulness, and recorded rejection reasons
2 — PreparePrepare an exact change for human approvalDry-run, validation, rollback, and approval binding
3 — Execute boundedPerform reversible, low-consequence actions inside explicit limitsSustained task success, monitoring, recovery, and a low override rate
4 — Execute with escalationOperate a bounded workflow and escalate deviationsMature control evidence and named operational ownership
Never delegated by default MoneyAccess grantsLegal commitments Regulated decisionsDestructive operations
Ownership

Your platform, your data, your exit

Deployment is your choice

Client-managed, operated by us, or a shared managed control plane. The architecture does not assume one, and the choice is documented with its trade-offs rather than sold as an obvious answer.

Open standards, no capture

No single mandatory model, agent framework, cloud, or vector database. A stated exit path is part of the design, and we would rather lose a lock-in argument than win a renewal you resent.

Not an unlimited-custom subscription

70% supported core, 20% configuration, at most 10% client-specific code. Open-source components do not eliminate implementation or operating cost, and we will not pretend they do.

What this is not: an autonomous replacement for your operating model; a requirement to move every conversation into a new product; a generic chatbot builder; an unrestricted collection of agents with broad credentials; or a system that grants agents final authority over money, access, legal commitments, regulated decisions, or destructive operations by default.

— The exclusions are part of the design, not the small print

You do not buy the destination. You buy the next rung.

A client asking to start at rung 4 is describing an outcome, not a starting point. Coordination without governed execution and assurance underneath produces exactly the incidents that fill the market’s case studies. We would rather tell you that than agree with you and invoice for it.

Find your rung → See the module catalogue