How to design agentic job-matching workflows

A traditional job-matching system waits. You enter a search, it retrieves results. An agentic system acts proactively based on a model it has built of you over time.

The defining characteristics of an agentic job-matching system:

• Continuous inference — the system forms and updates a model of your skills, preferences, and career trajectory from behavioural signals (applications, saves, views, role changes)
• Proactive surfacing — it delivers relevant opportunities without being asked
• Feedback loops — your reactions to what it surfaces refine its model
• Goal alignment — it optimises for your career outcomes, not just engagement

This creates a fundamentally different design challenge. You are not designing a search interface. You are designing a relationship.

Three tensions define the design problem in agentic job-matching:

1. Autonomy vs. control The more the agent does on your behalf, the less visible its reasoning is. Jobseekers want relevant results without needing to explain themselves constantly — but they also want to understand why something appeared. The design solution is not a toggle. It is graduated transparency: show enough reasoning to build trust without overwhelming with mechanism.

2. Implicit signals vs. explicit preferences Agentic systems are most powerful when they learn from behaviour, not just stated preferences. But stated preferences feel respectful and controllable. The best systems blend both: use implicit signals as the primary model, surface explicit controls as an override layer.

3. Precision vs. serendipity High precision means only showing things that closely match your model. But career growth often comes from unexpected adjacent roles. Agentic job-matching should have a deliberate serendipity budget — a portion of surfaces dedicated to roles that stretch your model, not just confirm it.

The feedback loop is the most important surface in an agentic matching product. Every interaction is both a user action and a training signal.

Key feedback moments to design carefully:

• Apply — strongest signal, highest intent
• Save — interest without commitment
• View duration — passive interest signal
• Dismiss — explicit rejection (design this to be effortless and useful)
• Not now vs. never — distinguish temporary context mismatch from genuine disinterest

The dismiss action is underdesigned in most products. If a user dismisses a role, you want to know why — but asking every time creates friction. The solution is light categorical dismissal: "Not the right level", "Too far away", "Not interested in this company" — three taps, useful signal, no paragraph required.

An agentic system that surfaces jobs without explanation feels like magic — until it surfaces something wrong. Then it feels like a black box.

Designing for trust means making the system legible at the right moments:

• Show reasoning when the match is non-obvious ("We surfaced this because 3 of your recent applications were in this sector")
• Surface confidence signals, not just results ("Strong match", "Partial match")
• Make recalibration easy ("I've changed direction — update my profile")
• Never pretend the system knows more than it does

At SEEK, I found that lightweight reasoning labels — shown contextually, not as a permanent UI layer — improved both engagement and reported trust without adding cognitive load.

Designing the GenAI Career Feed at SEEK, which anchors SEEK's FY26 OKRs, surfaced several non-obvious lessons:

Latency is a trust issue, not just a UX issue. When an agentic system takes time to respond, users fill the gap with doubt ("Is it struggling to find anything for me?"). Skeleton states and progressive disclosure matter more in agentic products than in search.

The first surface matters disproportionately. The first jobs an agentic system surfaces shape the user's mental model of what the system thinks of them. A poor initial match feels like a mislabelling of their identity, not just a bad result.

Designers need to own the model, not just the UI. In traditional products, designers own the interface and data teams own the model. In agentic products, the model is the product. Designers who cannot engage with the model's parameters and training signals cannot do their job well.