Aimily Context Review

From agent signal to governed collection truth: Context Graph diffs, exact-hash human approval, signed receipts and undo for fashion teams.

Comment

A meeting should not silently mutate a collection

Fashion decisions arrive as messy human context: a buyer meeting, a fitting image, a voice note, or a direct instruction. Personal agents are good at carrying that context, but giving an agent direct mutation authority over collection truth creates a trust problem.

Aimily Context Review turns the signal into a governed revision instead.

A personal agent enters the live workspace through WebMCP. Aimily resolves an exact before-and-after diff, maps downstream consequences through a Context Graph, separates explicit evidence from deterministic consequences and labelled inference, and preserves bounded alternatives. Nothing changes until a human approves the exact SHA-256 artifact hash.

After approval, a buyer-ready brief becomes available. The agent can apply only that approved artifact to an isolated preview. Every transition creates a chained receipt that the server verifies across seven invariants: hash, link, artifact, sequence, policy, chronology and identity. Undo restores the preview without erasing the decision record.

The agent brings the signal. Aimily owns truth, policy and recovery. WebMCP is the doorway.

What people and agents can now do together

  1. The agent reads the current collection context.
  2. It drafts connected intent-level changes across creative direction, materials, pricing and calendar.
  3. Aimily resolves values, rationale, evidence and confidence.
  4. The Context Graph exposes affected areas, uncertainty and unselected alternatives.
  5. A human approves the exact artifact hash in the interface. Approval is never agent-callable.
  6. The approved brief and apply intent appear only after approval.
  7. Apply changes only the signed Challenge preview, never production collection data.
  8. The receipt chain proves what happened and undo remains available.

The WebMCP tool inventory changes with the governed lifecycle. Context starts with three tools. Impact inspection appears only after a draft. The approved brief and apply appear only after exact-hash approval. Apply disappears after use and undo appears. The authority boundary is visible in the interface and generated from the same tool objects registered with the browser.

Why WebMCP is essential

This is not a chatbot beside the product. WebMCP gives the personal agent narrow, page-scoped access to the same signed collection state the human is reviewing.

The page uses document.modelContext.registerTool() to expose typed intent tools. Read operations use readOnlyHint: true; draft, apply and undo use false. Every source-bearing tool uses untrustedContentHint: true. Inputs use strict JSON Schema, results are structured, cancellation propagates with AbortSignal, and every result states the next valid action and whether production data changed.

The tools never read the DOM and never interpret screenshots. They call a same-origin server boundary backed by the shared deterministic collection-revision domain.

How we built it

  • Next.js 16, React 19 and TypeScript.
  • Seven page-scoped WebMCP intent tools with dynamic registration and abortable lifetimes.
  • HMAC-signed HttpOnly session and signed state pointer.
  • Same-origin enforcement, per-IP rate limiting and strict Zod validation.
  • Exact-hash approval, stale-state, replay and cross-session protections.
  • SHA-256 chained receipts verified before each new state token is signed.
  • A shared pure domain for revision, Context Graph impact and approved brief generation across UI, WebMCP and tests.
  • A separate Vercel project with a deployment-only signing secret and no canonical Aimily credential.
  • A public sample collection and isolated preview. No Supabase or production data path exists in the Challenge package.

Challenges we ran into

The hardest problem was not registering tools. It was making authority legible and enforceable across a lifecycle.

A stale agent handle must not retain authority after the state changes. A human approval must bind to an exact artifact rather than a conversational summary. A valid token from one session must fail in another. Rejected attacks must not corrupt the valid state. Receipt history must remain trustworthy through apply and undo. The visible authority list must never drift from the native browser inventory.

We addressed those risks with dynamic registration, server-side policy, exact-hash approval, session-bound signed state, seven receipt invariants and an acceptance runner that compares the visible governance rail with the browser's native tools at every stage.

Evidence, not claims

  • 37 focused Challenge tests pass.
  • A 16-control production red-team passes origin, schema, session, tampering, prompt-like evidence, approval order, artifact hash, replay, cross-session isolation and the complete approval, apply and undo receipt chain.
  • Chrome 151 natively discovers and invokes the full lifecycle on public HTTPS.
  • ChatGPT's in-app browser independently proved native context read, governed draft, dynamic registration, stale-handle rejection, readback and impact inspection.
  • Desktop and mobile runs preserve three chained receipts, seven valid integrity checks and production_data_changed: false.
  • The public repository passes a clean install, dependency audit, focused tests and production build in protected GitHub Actions.

Existing product and Challenge-period work

Aimily existed before the Challenge. Its private product architecture and full collection-creation system are not being entered as newly built work.

The Challenge-specific extension was built after submissions opened on 25 August 2026, with dated work beginning on 27 August. It includes the isolated signed sandbox, document.modelContext adapter, page-scoped intent tools, dynamic authority, exact-hash human approval policy, Context Graph review, receipt-chain verification, native Chrome and ChatGPT evidence, adversarial evals, public evaluation repository and the 75-second film.

The public AGPL-3.0 repository contains only the narrow standalone evaluation package and the shared deterministic revision subset it needs. It contains no canonical Aimily history, commercial pricing, billing, public landing, mobile application, production credential, production data, or canonical remote MCP implementation.

What we learned

The most useful agent is not always the one with the most power. Trust grows when the product can show exactly what the agent knows, what it inferred, what changed, who approved it, and how to recover.

WebMCP is strongest when it does not bypass product governance. It lets the agent enter the product's real decision boundary while the application remains the system of record.

What's next

The Challenge package is intentionally a public beta sandbox. The next product step is to bring the same governed signal-to-revision pattern into authorized signed-in collection workspaces, while keeping WebMCP as a doorway into Aimily rather than turning it into the product core.

Try it

Built With

Share this project:

Updates

Submission history