EventReady

Hiring vendors for an event is the part everyone knows how to do, and EventReady helps. The harder part is whether all of it holds together on the day, and that is what it keeps track of.

Comment

Inspiration

I was inspired by my day job and my hobby, as they both played a part to this idea. I work for a major grocery retailer that does catering, and we'll be launch a AI concierge chat bot soon. Watching that come together, I ultimately thought I could do better. It helps you build a basket inside one catalog, and you make a purchase. Easy peasy right, but what if your event requires purchasing and coordination across multiple vendors? You've got food from one vendor, tables from the venue, a friend driving warming trays across town, and there's no single place that knows whether all of it adds up.

The other half comes from concert photography. I shoot live music, which puts me in the parts of a venue an audience never sees, watching how a show actually gets run. Big events don't go well because every vendor is good. They go well because somebody's holding and coordinating across the seams. Who's where at what time, what happens when the truck's late, who owns the thing nobody put their name on. That work is coordination, and it's almost never written down anywhere.

EventReady points those two observations at the same problem. Hiring people for your event is the part everyone already knows how to do. The part that goes wrong is everything between them.

What it does

You describe the event, and EventReady walks it through five phases. Shape the brief, source the services, coordinate the owners and the money, close the gaps, then run the day.

The piece I care about most is the readiness layer. It reads what each provider has actually committed to, works out what that leaves uncovered, and tells you plainly what isn't going to work. Nobody's bringing the warming trays. The transport window doesn't fit the service time. Four responsibilities don't have an owner at all. Coordinate shows that as two columns, everything without an owner on the left and everything settled on the right, and a card crosses over the moment somebody takes it. Run turns the whole thing into a printable run of show with a real timeline.

The agent side isn't a second product. Nine WebMCP tools sit on document.modelContext, and they mutate the same EventSession the visible interface renders. An agent can assess readiness, compare plans, change the service level, assign an owner, or pull the run of show, and you watch it happen in the UI. Every change writes a decision receipt with before and after cost, coverage, ownership and readiness, so you can see what a tool call actually did instead of trusting that it did something.

How I built it

Using a combination of Codex and Claude Code. Deployed onto Vercel.

Challenges I ran into

Mostly compounding defects working across two different agents and environments. I have multiple setups and the commits and merges kept colliding. So I had to hand a lot of the refinement and polish more to Claude Code as Codex was really churning. Codex was mainly where I tested the WebMCP protocol in the in app browser.

Accomplishments I'm proud of

I was able to get a viable working concept up and running pretty quickly. Even though it's not perfect, with some additional tuning it could be really helpful with tons of integration potential across a variety of cases and industries.

What I learned

Most of what an agent does on the web today is guesswork. It reads rendered text, infers structure that was never declared, and hopes the number it pulled off the page is the number the page actually meant. That's slow, it burns context on markup that carries no meaning, and it's wrong often enough that you can't trust it with anything that matters.

WebMCP flips that. The page declares what it can do and what it knows as narrow typed contracts, so the agent reads a structure instead of reverse engineering one. Nine outcome shaped tools replaced what would otherwise be thousands of DOM nodes to crawl and guess at. The agent doesn't ask what's on the screen, it asks whether the event is ready, and gets back a typed answer with coverage, blockers, ownership and timing already resolved.

The accuracy gain matters more than the speed. Because the tools mutate the same session the interface renders, the agent and the person are reading one number, not two that drifted. There's no second pipeline to keep in sync and no chance the agent reports a total the screen disagrees with. I built a source gradient demo to check this properly, comparing what's knowable from WebMCP tools against schema.org markup, a plain price table, a document transcript, and a provider that publishes nothing. The difference isn't subtle. Structured capability is the only one of those that lets you act with confidence rather than infer and hope.

The part I didn't expect is that structure is also what makes safety possible. When provider data arrives in fixed declared fields, you can draw a hard line between data and instruction, because you know exactly which bytes are which. Free text gives you nothing to defend. My hostile vendor fixture is only defeatable because its blurb is a field with a known role, so a sentence aimed at the agent can be quarantined instead of obeyed. Standardizing the shape of the data is what made the trust boundary enforceable at all.

What's next for EventReady

Scale to make it functional end to end. Full catalogs and payment processing? Provenance on every row, so you can see which obligations the engine derived from a contract and which ones a person added. Real provider handoffs behind the copy-the-checklist step. And multi-device collaboration, which is honestly the whole point of coordination work and the one thing this build deliberately doesn't claim to do yet.

Built With

Share this project:

Updates

Submission history