Make the translation visible.

A vocabulary problem inside a matching problem

Candidates and employers can describe similar work in very different language. A person may have relevant experience without using the phrases a job description expects. Versed explored how to make that relationship easier to see while keeping the candidate’s actual experience as the source.

I owned the product end to end, from its direction and interface to the data pipeline, agent behavior, and implementation. Coding agents supported the build, with shared contracts and review connecting the backend and frontend work.

The first version was a job feed. It collected listings, matched them to a candidate, explained a fit score, and helped tailor a résumé. There was useful translation happening inside that process, but it was largely hidden behind the ranking and rewriting.

Put the differentiating behavior in the interface

Feedback on the demo exposed the problem: the underlying idea was clearer than the experience of using it. A list of scored jobs did not make the translation itself tangible.

I shifted the product toward showing the relationship directly: the employer describes a requirement this way; here is the relevant evidence from your work; here is how those two connect. That gave the user something to inspect, accept, or question.

The interface evolved through conversational and spatial concepts. The launch slice ultimately narrowed to a capture flow: a role, a job description, a résumé, and visible translation artifacts. The richer canvas sat behind that simpler entry point. The important product move was bringing the explanation into the experience instead of asking a score to carry all the meaning.

An illustrative mapping, using the customer project in this portfolio:

• Source evidence: I owned a customer agent from product scope through implementation. It is live in production.
• Example employer requirement: Own AI products end to end.
• Supported translation: End-to-end product and technical ownership of a production agent.

The wording changes, but the underlying claim stays attached to the work that supports it. Nothing in that evidence establishes a particular adoption level or business result.

Ground the language, then control the output shape

I built a competency catalog from job-description language to give the translations a shared reference. The pipeline extracted phrases, embedded and clustered them, and organized related vocabulary. The catalog was intended to support consistent mappings between the candidate’s language and the employer’s requirements.

The agent layer used a planner to select work, a dispatcher to run tools, and a deterministic assembler to turn their outputs into typed interface artifacts. Model-generated commentary streamed alongside those artifacts. The card assembler itself made no model calls.

That separation let the product define the shape of an explanation, résumé change, or job result in application code. The model could help interpret and explain while the interface retained a predictable structure. It also gave the backend and frontend a concrete contract to verify together.

Spend reasoning where it adds value

The earlier matching pipeline used vector similarity to select a smaller set of jobs before asking a model to score them against a structured rubric. That was a deliberate cost and throughput decision: evaluating every available listing with a model was expensive and created a backlog.

The rubric broke the result into dimensions such as skills, role fit, and experience, with reasoning attached. A shared model-call layer handled budget tracking and usage controls. These choices made cost and explainability part of the product architecture rather than something to address after the interface.

What the build taught me

Several significant failures happened between components. A router could exist without being mounted. A frontend could pass against a stub while missing a real backend contract. A grounding pipeline could produce data under a label that its consumer never read.

The response was to verify individual functions alongside the real application and its shared contracts. Those integration failures also became part of the correction evidence that led me toward Calx.

The other lesson was about scope. The build accumulated a substantial system before there was evidence of user adoption. Technical completeness and product validation were separate milestones, and the former could advance much faster.

Current state

Versed is shelved as a product. I reuse components in my own job search.