The conversation about who reads your website has been shifting. Agents are part of it now. ChatGPT fetches URLs. Perplexity reads content. Shopping agents try to complete purchases. Coding agents hit your API. Most of those products were built for humans, tested against humans. The agents showed up later and quietly. When they can't figure something out, they don't complain. They just bounce.
I heard the phrase "second audience" at a hackathon where you.com was one of the hosts. It stuck. That's what agents are: a second audience the web wasn't designed for and isn't being measured against.
And now, I want to build something about it. A scanner that tells you what an AI agent experiences when it tries to use your website or your API. The internal name is Perseus Clew and the public product is Agentis Lux. The split is intentional: Perseus Clew is the engine name, part of a suite of AI builder tools, and Agentis Lux is the product-facing name (Latin for "light of the agent") that describes what agent users see.
This isn't a launch post. I just finished a docs phase, and I'm about to write code. Before I do, I want to put this in front of dev.to builders and find out what I'm missing.
Three layers:
Deterministic scanning. Twelve check categories — six for frontends, six for APIs — looking at HTML, ARIA, structured data, OpenAPI specs, error responses, idempotency patterns. Same input, same score, every time. The methodology will be published, the weights will be public, and anyone can audit it. AI-readiness scoring tools have a reputation for inflating numbers and hiding their methodology, so the trust floor is making everything inspectable. That's the foundation the rest sits on.
An AI-written verdict. After the score, a Bedrock call reads the top findings and writes one sentence about what an agent experiences. Something like: "An agent visiting this page can read your product descriptions, but can't tell which button starts checkout, so it can't finish a purchase on its own." That sentence is what a human reads first. The number is the proof underneath it.
An agent simulation. Bedrock runs structured tasks against the scanned content and reports back: here's what an agent could do, here's what it couldn't. Turns findings into a story instead of a spreadsheet.
The score is deterministic. The explanation is AI-generated and labeled as such, and the simulation is the narrative layer on top. Each layer earns its role: math where consistency is important, AI where judgment helps, simulation where you need to know whether an agent can complete a real task.
Here's the result view — mock data, real design. The locked palette is Lance Wyman-inspired: cream, deep teal, sienna. Typography pairs Archivo Black with Instrument Serif italic for the AI line. Score on the left as one unit.
The "AI written" tag is intentional. I want a reader to be able to see which part came from a model and which came from math.
Free anonymous scan is the front door. The value is the signed-in tier: track your score over time, see your delta after you ship changes, eventually run it in CI so every PR goes through Agentis Lux before merge.
I'm entered in the H0 hackathon B2B track (deadline June 29) — submission at h01.devpost.com if you want to follow along.
Next.js on Vercel. API routes handle scan initiation and direct DynamoDB reads. AWS Lambda for the scan engine. Bedrock for the AI pieces. DynamoDB for benchmark data, plus ephemeral 24-hour TTL results so shareable links work. EventBridge for monthly benchmark refresh. CDK in TypeScript for the AWS side. Docker so it all runs locally.
Two DynamoDB tables by design: a 15-minute URL-hash cache so I'm not hammering target sites, and a 24-hour opaque-id result store for shareable links. Different keys, different lifetimes, different purposes. I went back and forth on merging them. The lifetimes don't match, so separate won.
Built with Kiro.
Three things I don't know:
Is the auth stub the right scope, or am I shipping too much, or too little? I'm building auth (email magic link), a user table populated on sign-up, and a scan history view that renders with an empty state, but no trend charts and no score-over-time. That sits in the middle of two clean alternatives. Smaller version: skip auth entirely, generate a per-scan email link for retrieval. Bigger version: if I'm shipping auth, ship the trend chart too because that's the actual recurring value. I picked the middle because I think it answers "who cares about one scan" without pulling trend tracking into the MVP.
Would you pay to track your score over time? Anonymous one-shot scans are easy. Recurring value is the business question. Be honest: do you, personally, building what you're building, care enough about agent-readiness to want trend tracking?
Findings only, no fix suggestions. Right now the product surfaces what agents see — "an agent can't tell your button is a button" — but doesn't tell you what to do about it, because that would mean knowing your codebase. I think this is a feature for builders who want visibility without being told how to fix it. It could also be the thing that makes a frustrated user close the tab. Which is it?
Block 0 starts this week. First end-to-end deploy: Next.js on Vercel, scan Lambda on AWS, the result hero rendering from mock data, the DynamoDB write seam stubbed in. I'll post again when the first real scan runs against a real URL.
If you're building something adjacent, or you have opinions about agent-readiness as a category, I want to hear from you. AI assisted. Human approved. Powered by NLP.
Created for the H0 Hackathon. #H0Hackathon