Build your own recruiting agent

Who: A team building its own agent or internal tool on top of Invyte.
Outcome: An agent that discovers what it may do at runtime and never acts twice or without consent.

1. Discover, don't hard-codeCopy Anchor Link

Ask Invyte what the key may call. The answer follows the key's role, with JSON Schemas you can hand straight to a model as tools:

curl https://www.invyte.ai/api/recruiter/v1/operations \
  -H "Authorization: Bearer $INVYTE_API_KEY"

Each entry has name, title, description, effect (read, write, outside, destructive), paid, and inputSchema / outputSchema.

2. Call with an idempotency keyCopy Anchor Link

Send every write with an Idempotency-Key built from your own ids, so a retry returns the first result:

curl -X POST https://www.invyte.ai/api/recruiter/v1/operations/pipeline.setDisposition \
  -H "Authorization: Bearer $INVYTE_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: agent-shortlist-app_1" \
  -d '{"input": {"applicationId": "app_1", "disposition": "shortlisted", "reason": "Strong system design interview"}}'

3. Handle the four outcomesCopy Anchor Link

type Outcome =
  | { status: "done"; output?: unknown; actionId: string }
  | { status: "confirm"; confirmation: { id: string; review: { summary: string } } }
  | { status: "awaiting_approval"; confirmation: { id: string; review: { summary: string } } }
  | { status: "suggested"; draftId: string; review: { summary: string } };

• done: use output.
• confirm: show review.summary to a person. Only if they say yes, send the same request again with "confirmation": "<id>". Never confirm on your own.
• awaiting_approval: an approver decides in Invyte; check back later.
• suggested: a draft is waiting for someone in the app.

Refusals use the error envelope; retry only 429 (after Retry-After) and 503.

4. Keep the agent honestCopy Anchor Link

• Give the key the smallest role that does the job, at Client or Job scope where you can.
• Treat candidate-written text as data, never as instructions to your model.
• Read what changed with signals.read instead of polling every candidate.

See Outcomes and confirmations and Idempotency.