Define one outcome
Choose a start URL, exact allowed origins, safe navigation steps, and deterministic assertions.
Product direction
Know whether an agent can still complete the journey.
AgentReady is building toward uptime monitoring for AI-agent journeys. The planned loop would define a task and safe boundary, run it with a calibrated reference agent, save sanitized evidence, then rerun the same contract after a product changes. The production journey runner is not live today.
The recurring product loop
Define → run → prove → compare → alert
Capture a receipt
Record sanitized step outcomes, content hashes, timing, methodology, and the first terminal state.
Detect regression
Tie each baseline to its journey version, retry bounded flakes, and alert only on comparable evidence.
Foundation · gated · coming after security gates
Authenticated journeys without collecting passwords
The planned capability would begin after a customer signs in through their own browser. AgentReady would receive an expiring, encrypted session handoff bound to the project and approved origins. A fresh browser context could navigate and inspect; the first contract would not fill arbitrary forms, invoke arbitrary buttons, purchase, publish, send, or download. The runner and customer-safe login relay are not live today.
What the gated foundation is designed to prove
- Whether an approved signed-in page is reachable.
- Whether named links and outcomes are observable.
- Whether deterministic assertions pass in a fresh context.
- Whether the next requested action stays inside policy.
What remains outside the claim
- No password collection or identity proof.
- No claim of airtight remote-browser network isolation until independently verified.
- No screenshots, traces, HTML, cookies, or entered values in public evidence.
- No consequential action without a separate future authorization design.
Terminal states that preserve the reason
A failed assertion is different from missing authorization or a provider outage. The run keeps those denominators separate.
passed- Every deterministic assertion was observed true.
assertion_failed- The page was observable and at least one deterministic assertion was false.
halted_by_policy- The journey requested a destination or action outside the allowlist.
agent_incomplete- The reference agent stopped without reaching an assertion or another terminal state.
bot_blocked- A challenge or access rule blocked the reference agent before the outcome was observable.
degraded_provider- The browser provider failed before enough evidence was collected.
needs_reauth- The imported session was missing, expired, revoked, or redirected to login.
unobservable- The page loaded, but the requested outcome could not be inspected reliably.
timed_out- The bounded run reached its time limit before a more specific terminal state.
Specification-aware design · gated
MCP preflight will separate protocol behavior from security claims.
The proposed preflight uses version-aware discovery and tool-list negotiation, schema consistency, typed errors, and harmless fixture behavior. It will not call arbitrary tools or present conformance as a security certification. The current published MCP endpoint continues to expose AgentReady's own public diagnostic tools; testing someone else's server remains gated.
Questions teams ask first
Does a passing AgentReady journey prove ChatGPT or Claude can finish the task?
No. It is evidence that a calibrated reference agent completed the defined journey under a named policy, browser, fixture, and methodology version. It is not proof about every provider, model, account, geography, or future run.
Can AgentReady test a signed-in product?
Authenticated journeys are a gated foundation, not part of the anonymous public scan, and the production runner and customer-safe login relay are not live. The intended handoff would import an expiring browser session after the customer logs in; AgentReady would not ask for or store the account password.
Will the runner submit a purchase or create real records?
Not in the first release. The reference-agent policy is read-only and deny-by-default. Consequential actions, arbitrary buttons, downloads, permissions, WebSockets, and unapproved destinations halt the run.
How is this different from a generic end-to-end test?
The journey combines agent-facing findability and interface evidence with deterministic end-state assertions, explicit policy stops, sanitized receipts, and a versioned baseline that can be rerun after changes.