LOCAL AGENT EXECUTION BOUNDARY

Delegate.Withoutletting go.

An execution boundary between your AI client and its tools. Fix what can be called. Isolate execution. Keep results and evidence. Development is moving that foundation toward a Linux Rust core and React / TypeScript Web UI.

Follow progress on XAsk about Waypost

PRIVATE VERIFICATION & DOGFOOD / NOT RELEASED

01 / THE EXECUTION BOUNDARY
ROUTE DOCTORInspect before launch
WaypostTools admitted at startup
AI clientThe caller
MCP backendOne execution destination
Admitted calls
Results & evidence return
Isolated generation
01 / CLIENTAI clientThe caller
02 / WAYPOSTTools admitted at startupRoute Doctor · Inspect before launch
03 / BACKENDMCP backend × 1Isolated generation

↑ Results & evidence returnResult → Receipt → AI client

FIG. 01A diagram of the current execution route. Not a product interface.
LINUX / WSL2LOCAL STDIOONE MCP BACKENDWhere we are

01 / WHY A BOUNDARY

Connected doesn’tmean controlled.

A visible tool is not a guarantee of safe execution. Where an agent’s intent becomes an effect in the world, there needs to be a boundary.

01

Can a new tool quietly gain access?

One startup inventory defines admission.

02

Where does execution cleanup stop?

Handle only the runtime you own.

03

What happened, and what remains?

One route from the call to its evidence.

02 / ONE CONNECTED ROUTE

Before the call.Through the return.

Waypost doesn’t manage how an AI thinks. It manages the route through which tools execute. Four connected contracts make up the working core.

  1. 01

    Decision

    Check the execution boundary

    Admit calls against an immutable inventory captured at startup.

  2. 02

    Invocation

    Dispatch the admitted tool

    Route to one MCP backend in its own isolated generation.

  3. 03

    Result

    Receive the outcome

    Bound cancellation and deadlines. Handle public-safe results.

  4. 04

    Receipt

    Keep execution evidence

    Connect decision, invocation, and result. Not a guarantee of parent-task completion.

The working core’s route. Not a human approval interface or a guarantee of parent-task completion.

03 / IMPLEMENTED, NOT RELEASED

A small, explicit execution surface.

Local stdio · one MCP backend. These foundations have been verified in bounded development environments; not all have migrated to the new Rust core.

01

Inspect before launch

Route Doctor checks route configuration and required artifacts before the backend starts. Know the route before execution begins.

02

What is listed is what can run

The startup tool inventory is immutable. Tools added mid-session do not automatically gain permission to execute.

03

Isolate execution. Keep evidence.

Isolate the runtime for each launch. Copies of verified inputs live in a private transient filesystem, with storage and lifetime separate from durable audit records. Public-facing results are designed to exclude sensitive data.

Explore the technical scope
MCP entry
Newline-delimited JSON-RPC over local stdio: initialize, notifications/initialized, ping, tools/list, tools/call. Protocols: 2024-11-05 / 2025-03-26 / 2025-06-18.
Artifact admission
Check path, owner, mode, inode, size, and hash. Validated artifacts and executables enter the route; later source-file changes cannot enter the running route.
Runtime & results
Manage runtime resources by ownership, with bounded cancellation and deadlines. Transient verified inputs are separate from audit records and the durable journal. This arrangement has been observed in ordinary use, but does not guarantee complete cleanup under every failure or an end to growth across all storage.
Connector diagnostics
Initialize and tools/list record success, failure, stage, and failure category in the current process. Not persistent, system-wide health monitoring.
Single-parent Task Assurance
Checks declared scope, evidence, and post-mutation state, closing only the verified scope. An opt-in local journal supports saved-result recovery across connections, bounded completion, and evidence export. The same request key and content returns the original result; different content is rejected. Revision checks prevent stale overwrites, and MCP results are size-checked before persistence. This is not an unconditional exactly-once guarantee for external effects.

04 / FIELD NOTES

From core to local UI.The product comes next.

PUBLIC STATUS

Development status as of October 9, 2026. Migration to a Linux Rust core and React / TypeScript Web UI is underway. The bounded verification below is not general availability or business readiness.

Follow progress on X
VERIFIED / LINUX LOCAL UI

A working Rust core and Web UI foundation.

The Rust core and React / TypeScript Web UI have run on Linux with read-only status views verified. A configured provider catalog and tool discovery from a single provider have also been tested within a bounded scope.

Evidence and verification scope

The new foundation has been tested with one call to a fixed synthetic tool. This is not a complete management interface or a way to enable arbitrary tools. Network providers and credential-dependent features have not been live-verified in this migration testing.

VERIFIED / SAVED RECOVERY

Reconnect. Recover the saved result.

Recover the saved original result after reconnecting, close the work within a verified scope, and export evidence. This bounded workflow has been verified in live use without conflating success, failure, cancellation, and unknown outcomes.

Evidence and verification scope

A real Codex client used human approval per request in a bounded recovery workflow. Requests, approvals, and results were matched, and exported evidence was checked against original data. It cannot recover results that were never saved and is not an exactly-once guarantee for external effects. This is separate from the test call on the new Rust foundation.

VERIFIED / LOCAL READS

Read the selected runtime, with explicit consent.

A bounded local-browser flow selected the same runtime and required explicit read authorization before showing its static launch contract and tool inventory.

Evidence and verification scope

Tool descriptions are bound to the same server's immutable inventory and its membership. A regular browser also obtained a valid native static configuration check within a bounded verified scope. That result is point-in-time: actual admission requires revalidation. A valid static check alone does not authorize launch or execution.

05 / DEVELOPMENT JOURNEY

Development journey

From connecting tools to an execution boundary for daily use. Progress has not been a straight line: repeated use has exposed problems that fed back into the design.

  1. Foundations for connections and contracts

    Beyond connecting tools, we established contracts linking decisions, calls, results, and evidence. This became the starting point for making execution scope explicit.

  2. Learning through daily use

    Using Waypost in our own AI development work has helped test the route from approval through execution to audit. It has also exposed operational challenges around startup, shutdown, and record retention.

  3. Resuming from saved results

    With human approval per request, we verified bounded recovery of saved results after reconnecting. We also tested a local-browser foundation for selecting the same runtime and reading it with explicit consent.

  4. Toward a Linux Rust core and Web UI

    Migration to a Rust core and React / TypeScript Web UI is progressing in stages. Status views, bounded discovery, and a test call have been verified, but migration is not complete.

  5. Separate lifetimes for inputs and audit

    Normal-shutdown checks were not enough: abrupt termination could leave temporary inputs behind. We moved verified inputs into transient storage within the isolated runtime and confirmed their separation from durable audit records in ordinary use.

06 / THE ROAD AHEAD

The next stretch of the route.

IN DEVELOPMENT / MIGRATION & DELIVERY

Toward a product people can trust.

Advance the Rust core migration while building permission controls, usable workflows, distribution, and updates. A working local UI foundation is not the same as a complete management product.

Read the verification boundary

Provider restart policies, ongoing health monitoring, and review across multiple tasks are not finished product features. A provider appearing in configuration or a catalog does not mean it is usable: authentication and health must be checked for each dependency. Bounded discovery and execution tests do not establish permission for arbitrary tools or formal support in every environment.

STARTUP / HISTORICAL MEASURE

Faster startup. Not a blanket guarantee.

Past development measurements observed shorter startup times. This is not a public benchmark or a measure of current product performance, and does not guarantee startup time in every environment.

Read the verification boundary

A single comparison without consistent OS or storage cache conditions. This is not a current remeasurement or a controlled benchmark. Multi-client compatibility and startup performance need product-level verification.

AUTONOMY WITH BOUNDARIES.

Building autonomy.With boundaries.

What works. What remains unknown. Follow the development route as it takes shape.

Follow progress on XAsk about Waypost