AgentReady.me

Goal contract builder

Planning artifact · Free browser tool

Journey Contract Builder

Create the execution contract AgentReady will use for public and post-login goal runs. This first release produces a deterministic, portable contract and planned TestRun; protected execution remains gated on scoped authorization and safe target infrastructure.

1 · Define and run

GoalContract input

Start with the included example, then replace it with one narrow customer goal and its real authority boundary.

Planning only: the generated TestRun records a plan, not an executed browser or post-sign-in journey.

Authority, assertions, and safe stop

Selecting a sandbox records a declaration in the contract; a later executor must still verify written authorization, isolation, fixture reset, and revocation. This public tool does not execute the sandbox run.

By running this tool, you confirm the submitted inputs are within your authorized scope.

2 · Inspect and export

Evidence bundle

Your structured result will appear here

Review the example GoalContract, adjust its boundaries, and run the tool. No action is taken beyond the boundary shown on this page.

Why this test exists

A practical AI agent customer journey test contract

“Can an agent use our site?” is too broad to test responsibly. A useful evaluation names a goal, a starting state, allowed origins, permitted actions, prohibited actions, success assertions, and the system that can authoritatively confirm the result.

The Journey Contract builder turns those decisions into a portable GoalContract and a planning-only TestRun. It works for public journeys and for post-login journeys you may execute later inside an authorized harness, without claiming that the public tool performed that execution.

Repeatable workflow

From a bounded goal to an inspectable receipt

  1. 1

    Describe one customer outcome

    Choose a concrete goal such as finding eligibility, preparing a booking, or reaching a test checkout.

  2. 2

    Draw the authority boundary

    List allowed origins and actions, prohibited actions, authorization scope, and the safe stop.

  3. 3

    Define success before testing

    Write observable assertions and identify the receipt, dashboard, API, or record that would be authoritative.

  4. 4

    Export the execution plan

    Download a planning bundle for a browser harness, QA owner, or post-sign-in runner to execute with explicit approval.

Read the evidence precisely

Four interpretation rules

A goal is singular

Keep each contract narrow enough that success and failure have an unambiguous meaning.

Allowed is not required

The allowed-action list bounds the test; it does not instruct a runner to take every available action.

Safe stop comes first

For a public or non-consequential run, stop before login, submission, booking, payment, deletion, or another write boundary.

Readback closes the loop

A confirmation screen is supporting evidence; an authoritative system record is stronger proof of a completed write.

Included in this tool

Observable checks and exports

  • Versioned and deterministic GoalContract export
  • Explicit target origins, allowed actions, prohibited actions, and safe stop
  • Success assertions separated from authoritative state verification
  • Planned TestRun and not-run OutcomeReceipt for honest handoff

Keep outside the claim

Known limitations

  • No credentials, session cookies, or private account data are accepted.
  • Post-login execution needs owner authorization, a disposable test tenant, fixture reset, and revocation.
  • A contract is an execution prerequisite, not evidence that an outcome occurred.

Frequently asked questions

What is a GoalContract?

It is a versioned statement of the exact task, starting state, boundaries, safe stop, success assertions, and independent readback required before a run can be evaluated.

Can this test my logged-in dashboard today?

Not in this public release. Authenticated execution requires scoped authorization and safety infrastructure for credentials, disposable fixtures, evidence retention, reset, and revocation.

Why is authoritative readback separate from visible success?

A success screen can be stale or misleading. Checking the system of record—such as an unchanged order count or a created test record—provides stronger outcome evidence.

Continue the investigation

Related tools and field research

See real journey-contract examples

Public scan projection

Agent Access Matrix

Compare robots policy, simulated agent user-agent responses, server-rendered content, browser stability, CAPTCHA, and security evidence in one public-site preflight.

Open tool

Local JSON analysis

Lighthouse Agentic Importer

Import a Lighthouse JSON report locally, preserve official audit IDs and display values, and turn observed failures into an agent-journey rerun checklist.

Open tool

Public scan projection

Stripe Link Checkout Preflight

Check the public substrate an agent needs before checkout: product data, structured prices, price parity, policies, HTTPS, and discoverable interaction evidence.

Open tool

Source-backed AgentReady analysis

Test Ai Agents After Login Safely Agent Readiness Score Vs Journey Success

Measured comparisons

Use receipts—not anecdotes—in a leaderboard

AgentReady's public leaderboard model requires owner opt-in, category fit, compatible scanner versions, observation windows, denominators, and evidence coverage. A tool export is an input to that process, not automatic publication.

View leaderboards

Need the whole public-site baseline?

Run the free AgentReady scan for discovery, semantics, browser compatibility, public forms, safety signals, and evidence-backed fixes.

Scan a public URL