---
title: "How we built v1 of a new kind of employment marketplace, Part 1: Giving a fast agent the right direction"
description: "How Cosmic reset a bloated AI-built prototype of a new employment marketplace by agreeing on user stories and information architecture before any screens."
canonical: "https://www.cosmiclabs.net/insights/building-an-employment-marketplace-part-1"
datePublished: "2026-09-22T21:57:37.033Z"
author:
  name: "Saad Ahmed"
  url: "https://www.cosmiclabs.net/company#saad-ahmed"
publisher:
  name: "Cosmic"
  url: "https://www.cosmiclabs.net"
---

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

## Short answer

An AI coding agent like Codex fills gaps in a product idea with familiar enterprise patterns: extra navigation, panels and status badges. On this marketplace v1 we reset the work by writing user stories first, deriving the information architecture from them and agreeing on it before any visual design. After that, the agent turned each correction into a revised plan quickly.

## Key takeaways

- A fast agent will build a complete-looking interface for a product nobody has agreed on, so settle the structure before reviewing screens.
- Write user stories, group the needs, and derive the information architecture from them before interactions or visuals.
- Start the experience where the user's material comes from. Here that meant a prompt for the candidate's workplace AI instead of a file upload.
- Give each concept one home: the narrative lives in Work history, and My profile controls how that same work is presented.

The first prototype Codex built for this marketplace worked. Every flow ran and every check passed. My first reaction was: wow, this was created very quickly, and it has the markings of a functional app.

But if you're designing for a human, it was plain to see what was wrong. The navigation labeling didn't make sense. The layout and content needed to be rethought. The wording in the UI was extraneous and unhelpful. It had a heavy sidebar, boxed sections, privacy explanations, status labels and supporting panels, and it looked like enterprise software, which was the one thing the founder's idea was supposed to get away from. I called it bloated, over-explained and "enterprisy," and the founder agreed.

So the job became curating and reining in a system like Codex or Claude, so it doesn't default to its training. I want to tell you how that went, because I think it's the part of building with agents that nobody warns you about. The agent wrote code faster than we could decide what the product was, and it kept answering that question before we'd asked it.

## A fast agent finishes the product before you've designed it

I started calling this premature completeness: an agent defaults to its training and builds a finished-looking answer to a question the team hasn't settled yet.

Once I noticed it, I saw it in three places on this project:

- **Navigation.** Every capability got its own destination and every state got a badge, so the first screen had navigation items for features nobody had agreed to build.
- **The first step.** Codex decided the candidate's first meaningful action was uploading a Markdown file, without asking where that file would come from.
- **The information architecture (IA).** It put the whole process of building a work narrative inside My profile, because that's where profiles usually live.

Each one was a reasonable default, and each one quietly made a product decision. (Every check still passed.)

**Information architecture (IA):** How a product's content and functions are grouped, labeled and connected. It decides what gets its own place in the navigation and how people move between those places.

The founder had hired [Cosmic to build the first version](https://www.cosmiclabs.net/work/evidence-based-talent-marketplace) of a new type of employment marketplace, and we were building it with Codex. Our job turned into pulling the agent back and telling it which decisions came first. I had to do that twice before we found a working rhythm.

## The idea was bigger than the screens

The founder's thesis was that in an LLM world, a resume is a poor account of someone's work. (Their stronger version: resumes are becoming useless.) A resume compresses a career into titles, keywords and a handful of polished claims. It leaves out the decisions, tradeoffs and context that would make someone worth interviewing.

The marketplace would hold a much deeper account of each person's work. Candidates would own it. Recruiters could read it themselves or point their preferred AI environment at it, with MCP as a first-class interface.

The founder brought technical references, a build specification and a color direction. I pointed Codex at the design-review method from another Cosmic project: a reference, a styleguide and a comparison gallery. I meant for it to borrow the review process. It borrowed the enterprise shape instead.

Our second 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, and 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.

## Andrej Karpathy's version of this works for weekend projects

The strongest case for letting the agent run comes from Andrej Karpathy, who named the practice. His description of vibe coding is to "fully give in to the vibes" and "forget that the code even exists."

He's right that this is fast, and he was candid about the scope: he said it's not too bad for throwaway weekend projects. I think that scope is the part people drop when they quote him. A weekend project has no human on the other end waiting to be told a story. A founder's v1 does: the people it's for have to understand it from the first screen. On this project the code was fine. What we'd have lost by giving in to the vibes was the narrative, because the agent was writing it by default.

So I changed the assignment, and the reason came from sales more than software.

The reason I successfully closed over $25 million in enterprise deals is that I was (and am) good at telling a narrative around the technology. When I had to help with this marketplace app, it was the same type of narrative thinking: thinking that only a human can bring to the table for another human to consume. Curating the story arc, the first screen, the order of the work, the potential emotional triggers. That's my role.

The system works fast. It can create pixels and write code. My job is to curate the narrative arc for the human consumer while building an underlying system that an agent can traverse. (On this product the second half was literal: recruiters' agents would read the same profiles over MCP.)

## We reset the order: people, then structure, then pixels

The new order was user stories first. Talk about the people using the product and group their needs. Derive the IA from those needs and agree on it before defining the interactions and content that live inside it. Only then go back to visual design.

The first correction moved the start of the experience earlier.

Codex had treated the Markdown upload as step one. The founder's answer to "where would that file come from?" 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. We didn't use its length or occupation as 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.

## Two readers, one account of the work

The personas were practical. One is the person trying to understand and present their own work. The other is 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.

## Work history earned its own home

Then came the 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.

Codex's proposal came from its training: profiles hold profile things. Mine came from the story. For a candidate, the story is the work, so the work gets its own place, and the profile is how that story gets 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: 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. Sharing a work profile would never reveal the candidate's email on its own.

## Where Part 1 left us

By the end, the core IA looked like this:

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

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.

Here's what I took from it. 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, to navigation items for features that didn't exist yet.

I think that's the job now, on any project Codex or Claude builds: curate the narrative arc for the human, build a system an agent can traverse, and don't let the agent's training make the product decisions. It's how we run every [AI software development](https://www.cosmiclabs.net/software-development-fairfax-va) project. The risk is that the agent's defaults are good enough to ship, so nobody notices they were decisions. We ended Part 1 with a structure the founder and our team could both explain and defend. [Part 2](https://www.cosmiclabs.net/insights/building-an-employment-marketplace-part-2) is what happened when we let the agent design screens on top of it.

## FAQ

### Why did the first AI-built prototype need to be redone?

Codex produced working flows and passing checks, but it copied a generic enterprise-app shape with a heavy sidebar, boxed sections, status labels and supporting panels. The founder's idea was buried under features nobody had agreed to build.

### What order should you design in when an AI agent is building?

Start with user stories, derive the information architecture from them, then define interactions and content, and do visual design last. Agreeing on the structure first stops the agent from rearranging screens for a product that isn't defined yet.

### How does a candidate build a work profile without a resume?

The product gives them a prompt to run in an AI tool they're allowed to use at work, covering a period of six to twenty-four months. They bring back a narrative they're permitted to share, and the product asks focused follow-up questions about anything unclear.

## Sources

1. [Model Context Protocol: introduction](https://modelcontextprotocol.io/introduction)
2. [OpenAI Codex](https://openai.com/codex/)
3. [Vibe coding, coined by Andrej Karpathy (February 2025)](https://en.wikipedia.org/wiki/Vibe_coding)