How we built v1 of a new kind of employment marketplace, Part 1: Giving a fast agent the right direction

Agents like Codex move fast. Give one a product idea, a repository and a few references, and it can produce a working prototype before you've finished deciding what the product should be.

That speed can also produce a system with ten navigation items, noisy explanations and enough enterprise-software habits to bury the original idea. Each capability gets its own destination, and each state gets a badge. Soon you're reviewing a surprisingly complete interface for a product nobody has agreed to build.

That is what happened when a founder hired Cosmic to build the first version of a new type of employment marketplace, and we started building it with Codex.

Our job at that point was to pull the agent back and tell it which decisions came first. I had to do that twice before we found a working rhythm.

What was the marketplace supposed to do?

The founder's thesis was that in an LLM world, a resume is a poor account of someone's work. The stronger version is that resumes are becoming useless. They compress a career into titles, keywords and a handful of polished claims, and they leave out the decisions, tradeoffs and context that would make someone worth interviewing.

The idea was a marketplace built around a much deeper account of each person's work. Candidates would own that account. Recruiters could read it themselves or point their preferred AI environment at it, and MCP would be a first-class interface.

The founder brought technical references, a build specification and a color direction. I also pointed Codex at the design-review method from another Cosmic project: a reference, a styleguide and a comparison gallery. The intent was to borrow the review process.

Why did the first prototype miss?

Instead, the first prototype carried over the familiar enterprise application shape: a heavy sidebar, boxed sections, privacy explanations, status labels and supporting panels. Codex had produced working flows and passing checks, and I still disliked the result.

I called it bloated, over-explained and "enterprisy," and the founder agreed.

The next attempt removed a lot of the chrome. Upload got simpler, privacy edits moved into the document, and recruiter results became a cleaner list. It was less crowded, but we were still rearranging screens before agreeing on the experience underneath them.

The one visual element worth keeping was the founder's logo mark. Everything else started again.

How did we reset the work?

I changed the assignment: start with "as a user" stories. Talk about the people using the product and group their needs. Derive the information architecture (IA) from those needs and agree on it before defining the interactions and content that live inside it. Only then return to visual design.

The first correction moved the start of the experience earlier.

Codex had treated uploading a Markdown file as the candidate's first meaningful action, without asking where that file would come from or what would make it a useful account of someone's work.

The founder's answer came from their own job. Their employer's systems already hold a detailed record of what they do, and tools like Glean, Zoom and Gong can feel like corporate surveillance. The founder wanted to turn that record into something that benefits the person doing the work: a deep self-review covering the last six, twelve, eighteen or twenty-four months.

That gave us a better starting story:

As a user, I want the product to give me a useful prompt for my workplace AI, so I can build a detailed narrative of my work.

The product would help define the period, role and scope. The user would take the prompt into an AI tool they're allowed to use at work, then bring back a narrative they're permitted to share. The prompt had to separate personal contributions from team results and keep restricted information out of the portable output. Removing a name afterward doesn't make something appropriate to take out of work.

The founder had a long-form career handoff of their own to use as a reference. It held work examples, a self-review, career interpretation, gaps and instructions for another assistant. We used its structure to calibrate the depth we wanted. Its length and occupation weren't a template everyone else would have to match.

From there, the stories got more useful. As a user, I want the product to point out what's unclear. I want a focused follow-up question, or another prompt I can take back to my workplace AI. I want to correct a claim, say I don't know, keep something private and come back later without starting over.

We also defined "enough information." The product should be able to explain the context, the person's responsibility, their decisions, the outcome and what remains uncertain, then say what another round would improve. It should never turn that into a completeness percentage, or keep interrogating someone until the document sounds impressive enough.

A useful private self-review became the first product value. Publishing into a marketplace could come later.

We split that first path from a second stage: uploading permitted source files, such as transcripts, and having the product analyze them directly. That path brings extra attribution, processing and source-review responsibilities. We left room for it without making the first experience depend on it.

Who is the product for?

The personas were practical: the person trying to understand and present their own work, and the recruiter trying to judge whether that work matters for a role. We also recognized the organization admin who controls payment and access. The recruiter's agent works on behalf of that person and organization, within their permissions.

The founder added another candidate story: when a recruiter reaches out on LinkedIn, I want to send my profile and tell them to point their agent at it.

That opened a second entrance to the recruiter side. Recruiters could discover someone in the marketplace or arrive with a profile already shared with them, and both paths had to lead to the same account of the work.

We settled the candidate's core activities as build, refine, approve and share. Signup would ask for a name and email, with broad location and a LinkedIn URL optional later. Resumes stayed out of the first version. Suggested jobs remained a future capability instead of a placeholder navigation item.

Where does each part of the product live?

Then came an IA disagreement. Codex proposed putting the whole narrative-building process inside My profile. I wanted Work history to be first class, with My profile holding everything else about the person and how they're presented.

That gave us a clear boundary. You build and correct the narrative in Work history. In My profile, you choose how it's presented, preview the exact shared version, approve it and manage visibility. Both draw on the same underlying work, so there are never two copies to keep in sync.

For recruiters, we set three priorities: discovery, a job requirement to discover against, and payments. A role had to describe the work a person would do, rather than supply a title for keyword matching. Recruiters would inspect relevant work and open questions, then decide whether to interview.

Agent connection needed to be prominent too. The product should encourage recruiters to work through Claude, ChatGPT or their preferred AI environment. We described a simple connection-link handoff, with direct MCP setup as a second path. We kept that desired experience separate from an untested promise that pasting a URL anywhere would authenticate an agent.

One open question was where a recruiter keeps profiles before assigning them to a role. I suggested Recent profiles, ordered by most recently viewed, with actions to add someone to a role, reach out or archive.

Sharing led to tokenized URLs with explicit expiration. The founder wanted links to expire loudly, with a clear deadline, a clear expired state and a clear way to create a new link. Exact durations and whether invited recruiters pay stayed open. Contact stayed simple. A conversation could happen entirely over email or an existing LinkedIn thread, so the product didn't need an inbox or a scheduling system, and sharing a work profile would never reveal the candidate's email on its own.

What was settled at the end of Part 1?

By the end, the core IA looked like this:

• Candidate: Work history, My profile
• Recruiter: Agents, Roles, Recent profiles, Organization

By then we had documented the user stories, information relationships, main flows, interaction rules and content direction. Three choices were still open: share-link durations, whether invited readers pay, and whether a lightweight contact-permission request belonged in the first release.

The UI wasn't done. Both earlier visual directions were rejected, and the screen-level interactions and content still needed work before wireframes.

We stopped the first part there, with a product structure the founder and our team could both explain and defend. Codex turned each correction into a revised plan quickly. Our part was saying no: to Markdown upload as step one, to burying the narrative inside My profile, and to navigation items for features that didn't exist yet. The next design pass had that structure to work from, and Part 2 covers it.