Skip to content
Staircase

Agents

The tool registry a client connects to, and the fleet itself — every agent listed by what it does.

The roster files every agent under the dimension it works on — the same ones the navigation runs on, plus the router and the agents that build other agents. The router is the way in: nobody memorises the roster, a task is described in plain language, and the router names the specialist and the skills that fit.

An agent that changes production behaviour shows its work before acting: a comparison over sample records, a dry run, and a human approval gate on the consequential step.

  • The network

    • Key services are documented well enough that an agent can rebuild them from scratch. The documentation is the system of record, which is what keeps it honest and current.
    • Building agents encode how a reliable service gets constructed, so each new runtime agent is assembled from proven patterns rather than designed from nothing. The cost of adding the next agent keeps falling.
    • An agent that touches production behaviour shows its work first — before-and-after comparisons, dry runs, and human approval gates — so people stay in control of every consequential decision.
    • Business users launch pipelines, change rules, request exports, and manage copy by writing plain-language requests, work that previously required an engineer running scripts.
    • Because specialists share the same skills and standards, services built years apart still look and behave like siblings — easier to operate, audit, and hand over.

  • Skills

    • Packaged, versioned know-how — how to integrate a partner, how to model data, how to test a design — that any agent or engineer picks up. Knowledge is written once and reused everywhere, so it compounds instead of evaporating when a person leaves or a system changes.

  • Registry

    • One index of every agent and skill, deliberately repository-agnostic: each row names the repository that defines it, so specialists authored in different packages sit side by side in one place. Nobody memorises the roster — describe the task and the router names the specialist.

  • Tools

    • One tool registry is the single source both transports read, so the stdio entry and the HTTP entry cannot drift apart.
    • Every tool carries a title, a description, and a per-parameter description written for a model rather than for a reader who already knows the domain.
    • Query tools are guarded in four layers: comment and literal stripping, multi-statement rejection, a read-only statement allowlist, and an unconditional row cap.

  • Fleet

    • Agent definitions are compiled from one source into three runtimes, so a behaviour change is written once and lands everywhere.
    • A router dispatches to specialists rather than one agent carrying every capability.
    • Skills are separately versioned units an agent composes, not prompt text pasted into a definition.

  • Evaluations

    • Behavioural fixtures assert exact tool-call arguments, not output similarity, and they run in continuous integration before a deploy.
    • A conversational agent that stops calling the right tool fails the build rather than degrading quietly once deployed.
    • Per-conversation model cost is reported to a budget surface, so an agent that becomes expensive is visible as a number.

  • Runtimes

    • The same registry is served over a standard-input transport, a streaming HTTP transport, and an edge runtime.
    • Documented, working install paths exist for five separate agent clients — this is a multi-client surface, not a single-vendor integration.
    • Configuration is environment-supplied, so pointing the surface at a different set of jurisdictions is a configuration change rather than a release.

Routing

The way into the fleet: one agent reads a request and hands it to the specialist that owns the work.

  • Router Reads the current roster and names which specialist and which skills fit the task, with the reasoning behind the choice.

Data

The records, the schema over them, and what is read back out — ingestion, retrieval, reporting, reconciliation and extracts.

  • Counterparty document expectations Loads counterparty contact details and document requirements from spreadsheets into the graph store, mapping each requirement onto the governed vocabulary and setting aside anything that does not map.
  • Data-lake assistant Answers questions over the accumulated loan and partner data in plain language, and draws the chart where a chart is the answer.
  • Dataset fulfilment Turns an approved data request into a scoped extract — resolving which organisation it belongs to, mapping the requested field names onto the canonical model, and returning either the result directly or a time-limited download link.
  • Knowledge search Builds reusable retrieval agents that answer from a curated document corpus — embeddings, a search index, a knowledge library, schema and header mapping, reuse of prior decisions, confidence thresholds and a human review loop.
  • Metric reconciliation Reconciles the same metric across vendors and sources so the figures compare like with like, and records why they differed.
  • Model curator Guards the shared graph schema, so that every entity type, relationship, property, index, enumeration and required field passes one review and ingestion and query behaviour stay consistent across services.
  • Pipeline control panel Runs the document-processing pipeline on request: resolves which documents actually exist for a set of records, checks what has already been processed, dispatches only the remainder, replays failures, and confirms the results reached their destination.
  • Property data exploration Answers questions about public property and business data in plain language — appraisal and parcel records, permits, registered companies, contractor reputation, geographic filters and the schema behind them — by driving the published tool surface rather than writing queries by hand.
  • Public record ingestion Brings a jurisdiction's public data online: discovers the sources, collects and validates them, loads and reconciles them into the query store, then publishes the jurisdiction's query table and coverage record and wires both into the tool surface.
  • Question answering Resolves which approved source actually holds a figure, queries it live, and turns the verified answer into a secure, shareable, refreshing report.
  • Report catalog Builds and maintains the single page where existing reports are registered and found, with a command-line path for registering a new one.
  • Search to production Takes a retrieval system from a local prototype through to production: the index model, the migration off the local store, historical backfill, live ingestion per source, and the instructions an agent needs to use it.

Products

The borrower conversation and the assistants around it, collecting the credit, assets, liabilities, employment, income and real estate owned that the Products dimension documents.

  • Application document Generates the completed application document from everything the conversation collected, and takes the borrower's signature on it.
  • Assets Collects what the borrower holds — deposit and investment accounts, the institution each sits with, and the balance.
  • Co-borrower invitation Invites a co-borrower into the application and starts their own task set, which is the borrower's set plus the questions only they can answer.
  • Contact details Collects how to reach the borrower — telephone numbers by kind, and the electronic-mail address the application and its documents are sent to.
  • Correction Reopens a subject the borrower has already answered so an answer can be changed without restarting the application.
  • Credit Takes the borrower's consent to a credit enquiry, runs it, and brings the result back into the conversation so the liabilities it reports can be confirmed rather than typed.
  • Declarations Collects the declaration questions the application requires, and the follow-up detail wherever an answer needs one.
  • Demographic details Collects the regulated demographic questions, including the borrower's right to decline each of them.
  • Employment and income Collects employment and the income that comes from it — employer, role, dates, and the pay in the components a lender underwrites: base, overtime, bonus and commission.
  • Frequently-asked questions Answers a borrower's questions from a curated knowledge base rather than from the model's general knowledge, with the source behind each answer.
  • Gifts and grants Collects funds given to the borrower rather than held by them — the donor, the relationship, the amount, and whether the funds have arrived.
  • Liabilities Reviews the debts the credit enquiry reported, corrects them, and collects the ones it did not — the obligations that do not appear on a credit file.
  • Loan lookup Finds an existing application from what the borrower can remember, so a returning conversation resumes rather than restarts.
  • Military service Collects service history, which decides eligibility for the loan programmes that depend on it.
  • Mortgage details Collects the terms of the loan being applied for and of any mortgage already secured on a property the borrower owns — amount, purpose, occupancy and term.
  • Other income Collects income from every source that is neither employment nor a business the borrower owns — rental income, benefits, pensions, investments, support payments.
  • Personal identity Opens the application and collects who the borrower is — legal name, date of birth, taxpayer identifier, citizenship and marital status.
  • Preapproval letter Produces the preapproval letter from the priced application, and refreshes it when the price behind it moves.
  • Pricing Runs an actual price against the collected loan terms and explains the result in the conversation.
  • Rate estimate Gives a borrower an indicative rate from a short conversation, before any application exists.
  • Real estate owned Collects the properties the borrower already owns — address, value, how it is used, and what it earns or costs.
  • Residency Collects where the borrower lives now and where they lived before, with the dates, so the address history covers the required period without gaps.
  • Self-employment income Collects income from a business the borrower owns, including contract income reported on its own tax form.
  • Workspace assistant The assistant inside the internal workspace: answers a reviewer's questions about an application in progress and drafts the message going back to the borrower.

Providers

A vendor integration or a counterparty exchange — a message provider's send-and-feedback loop, a partner's file share, a partner's client list, a third-party measurement console.

  • File sync Builds the scheduled workflow that copies a configured storage location into an external partner's file share: the infrastructure, a planning and cost gate, per-file workers, an aggregate, and the credential and configuration handling around them.
  • Marketing stack Orchestrates the whole measurement stack across consoles and code — tag management, analytics, search visibility, advertising linkage, the access each of those needs, and the handoff to whoever verifies it.
  • Roster workflow Takes each partner's uploaded client list, matches it against the records under management, and returns partner-branded settlement and authorisation paperwork the same day.
  • Send lifecycle Owns the whole dispatch and feedback loop as one lifecycle: provider setup, routing, the send handoff, delivery events, and ingestion of what comes back.

Delivery

Software being built, packaged, released, deployed or tested — scaffolding an application, distributing it to tenants, implementing a design, triaging what renders wrongly.

  • Analytics instrumentation Wires tag management into a front end on any of the common frameworks, and works out with the team which user actions are worth tracking.
  • Application scaffolding Scaffolds complete applications on the standard stack, front end and back end together in one repository, with the shared packages between them.
  • Design implementation Translates a design into existing interface code, preserving the business logic underneath and locking in the breakpoints.
  • Design testing Writes the tests that verify an interface renders correctly across phone, tablet and desktop, in whichever of the two lanes fits — mocked specifications for the design itself, or real-device specifications for behaviour.
  • Interface triage Triages and fixes interface defects: confirms the delta against the design reference, audits recent commits for the override that caused it, applies the smallest correcting change, and strengthens the tests so it cannot return.
  • Marketplace architecture Architects the multi-tenant platform through which products are packaged, distributed and installed — a central account governing per-customer accounts, a registry of components and releases, and the four ecosystem products underneath it: domain routing, account management, the product deployer and the tenant-side reconciler.
  • Sharing portals Builds secure external file-sharing portals: hosted sign-in, private folder browsing, per-user grants, administrator-managed accounts, a custom domain, runtime configuration and a design-matched interface.

Platform

What runs underneath: the conversation runtime and its queue, batch workflows, solvers, short links, template inventory, campaign operations and the capability map.

  • Audience selection Defines who a communication goes to, owning the entry point, the hard suppressions, and the contract by which an eligible population is handed to the runtime that will act on it.
  • Batch workflows Designs large-scale batch and extract-transform-load workflows with cost gates, throttling, idempotency and a staged test path.
  • Capability map Knows every internal platform capability — accounts, bootstrap, build, distribution, deployment, reconciliation, persistence, connectivity, translation, product orchestration, rule decisioning and the governed vocabulary — and decides whether a request is served by something already deployed before any infrastructure is written.
  • Channel assembly Composes audience, template and send capabilities into one deterministic end-to-end channel service — the internal data contracts, candidate generation, scoring, allocation, outputs and runtime validation.
  • Contact scheduling solver Holds how one deployed scheduling solver actually works — how it prioritises records, selects a contact point, respects capacity, assigns hours, rotates between contact points and labels score tiers — and extends it without inventing a parallel runtime.
  • Conversation management Manages the fleet around the runtime: the queue a conversation waits in, the configuration each agent runs from, and the tasks raised for a person when a conversation needs one.
  • Conversation runtime Serves the conversation itself: holds the task set, runs the agent whose turn it is, calls the functions an answer triggers, and writes what was said to the loan record.
  • Mail campaign operations Operates the deployed mail-campaign workflow: validating the population for a run, launching it, watching it, and reconciling what came back against what was sent.
  • Message assistant Answers questions about what has been sent to a consumer, and lets a non-technical user propose, revise, or retire a message template through a plain-language review conversation that captures the approved wording.
  • Rule editor Turns a plain-language request into a concrete change to phone-interaction rules, runs it against sample records to show exactly which numbers would and would not be called, and packages that before-and-after evidence for the rule owner to approve.
  • Short links Builds the link-shortening and click-telemetry service behind outbound messages: issuing short tokens, storing the link as a graph record, resolving a token through a graph query, redirecting, and publishing a click fact onto the shared event bus.
  • Solver services Designs and scaffolds optimisation services: a distributed layer that prepares data at scale, a pure solver core, and the infrastructure that wires them together.
  • Template inventory Builds the systems that keep message templates versioned, reviewed and in step with whatever sends them — the repository layout, the metadata contract, discovery of the source tables, and one-time or recurring synchronisation from the operational store into a version-controlled inventory.

Creating new agents

Agents whose output is another agent — the specification it is written from, the scaffold it is built on, and the evaluation set that gates it.

  • Assistant builder Designs and implements task-triggered agents on the established runtime pattern — one function receiving events from the work-management surface, conversation state held externally, a model doing the reasoning, and tracing on every turn.
  • Audit analyser Builds analysers that read pipeline output, apply versioned audit profiles, and emit evidence-backed anomaly records for a person to review.
  • Operations agent builder Builds the operations agents that drive document and media pipelines: resolving the target environment from what the requester said or from their profile, discovering the deployed stack, starting and watching runs, handling replays and approval gates, and preparing configuration changes as reviewable proposals.
  • Spend approval Builds the workflow that watches model spend against a threshold, opens an approval task when it is crossed, and raises the limit by a configured increment only after a human completes that task.

Type to search.