CASE STUDY · LIVE IN PRODUCTION · 2026

Talent Manager

A production-live agent that does real work. Lives inside Career Bot. Mirrors a scout → resolve → outreach protocol with explicit phase gates, a rate-limited HTTP executor, and a Slack approve/deny pre-filter for any side-effecting step. The reference pattern other service agents copy.

See it in Career Bot →

Why this exists

"AI agent" usually means: read text, return text. That's a prompt with marketing. A real agent does side-effecting work — it makes HTTP calls to other people's systems, it sends messages, it modifies state. Real agents need real guardrails: explicit phases, idempotency, rate limits, and a human in the loop where the cost of a mistake is high.

Talent Manager is the prototype I built to prove I could do that — safely — and ship it to production. It's now the template for everything else.

The state machine

Five phases. Each has explicit entry conditions, exit conditions, and a gate.

PHASE 01

Scout — discover

Crawls a seed list of company URLs looking for talent-API surface area. Looks at api.* subdomains, OpenAPI / Swagger paths, common career endpoints. Persists every probe outcome — found, 404, auth-required, timeout — so re-runs are idempotent.

Exit condition: scout_complete · Last run: 4 hits / 52 seeds

PHASE 02

Resolve — classify

For every hit: pointer-follow MCP resolver, classify into open or mcp_auth_required. Stores both; never assumes a 401 means "not interested" — it means "we need a credential." The classification is the contract.

Exit condition: resolve_complete · States: open · auth_required · unreachable

PHASE 03

Slack pre-filter — approve / deny

Before any outbound action: agent posts the proposed action to Slack with approve/deny buttons. No approval = no execution. Period. The cost of an unwanted outreach is reputation; the cost of a delayed outreach is a Slack notification I check anyway.

talent-manager-bot 2026-04-22 11:47

Proposed outreach:
  target: api.example.com
  channel: HTTP POST /v1/contacts
  payload: { ... 380 bytes ... }
  cost estimate: $0.04 · idempotency key: tm-2026-04-22-001

PHASE 04

Outreach — execute

Live HTTP dispatch. Rate-limit race fixed (Phase 5b). Idempotency keys on every request so a retry doesn't double-fire. Every call writes a row to MA — observable from /memory-archive/sessions. If the upstream rate-limits us, the agent backs off and resumes — not a tight retry loop.

Exit condition: response_logged · Idempotency: per-request keys

PHASE 05

Reconcile — update graph

After every outreach: write the outcome back to the Knowledge Graph as a node and an edge from the original target. Future scouts read the graph first; we don't re-prospect a target that already has a recent reconcile node.

Exit condition: kg_node_persisted · KG edge: outreach → target

The hard parts

Rate-limit race (Phase 5b)

Pre-fix: two phases could both observe "we're under the limit" and both fire. Fix: a Redis-backed sliding window with a single-flight lock; only one phase wins the slot. Quietly reliable since.

Pointer-follow MCP resolver

An MCP endpoint can return another MCP endpoint as a "pointer." Following pointers needs a budget (max depth) and a cycle check; otherwise a malicious or misconfigured pointer chain is a DoS on yourself.

Idempotency keys, not nonces

Every outbound HTTP call carries an idempotency key derived from (target, action, day). A retry is safe; a duplicate by accident is not.

Observability over guarantees

I can't guarantee remote systems behave. I can guarantee that every action TM took is in MA, queryable, with a Slack approval row attached. That's worth more than wishful guarantees.

What this taught the rest of the system

The Talent Manager pattern — phase gates + side-effect approval + idempotency + reconcile-to-graph — is now the template for any agent that does real work. The owner agents on each public service follow it. The Continuous Learning Agent follows it for memory edits. The next generation of mesh-agents will follow it for cross-agent dispatch.

"Phase-gated, idempotent, approval-pre-filtered, reconcile-to-graph" is now just how an agent works in this codebase.

More of the system

Talent Manager is the production-live agent. The roster has the rest. The Career Bot architecture page shows where it sits.

Agent roster → Career Bot architecture Memory Archive