Your model writes the answer. We submit the form.

An application agent and an ATS integration solve different problems. The agent interprets intent: why this role, how experience maps to a requirement, or which truthful option best fits the candidate. The integration handles protocol: field identifiers, select values, multipart uploads, session cookies, tracking fields, verification, and the final HTTP request.

Bring-your-own-agent mode draws the boundary at the discovered question. Apply Guy maps facts that are already deterministic. When it reaches a field that genuinely needs interpretation, it emits the same structured prompt and response schema its managed resolver would use—but makes your system the model provider.

Create the application with mode: "agent". Execution starts normally. If all fields map directly, the application can finish without calling your model. If an unresolved question appears, the existing application moves to awaiting_answers and keeps its credit reservation.

queued
  ↓
running ───────────────→ success | failed
  ↓ (judgment needed)
awaiting_answers
  ↓ POST schema-valid answer
queued → running ──────→ success | another answer round

After you submit a valid answer, the application returns to queued and resumes. Do not assume one pause is the maximum: the employer form may reveal another section later, or a live form revision may require a fresh request. Drive the workflow from state, not from a fixed number of model calls.

{
  "id": "00a8e87d-...",
  "fingerprint": "837c03d4...<64 hex chars>",
  "createdAt": "2026-08-23T18:04:11.000Z",
  "responseSchema": {
    "type": "object",
    "required": ["answers"],
    "properties": {
      "answers": { "type": "array", "items": { "...": "..." } }
    }
  },
  "prompt": ["ATS-specific model messages and discovered form context"]
}

The schema is the contract. It may contain discriminated answer kinds, option identifiers, arrays, required properties, and constraints specific to that ATS resolver. Passing only the visible question text to a generic chat completion throws away the information that makes the answer submit-safe.

Most structured-output libraries can accept arbitrary JSON Schema. Feed the returned prompt as external task context, add your own system policy above it, and require output against responseSchema. Then post the raw JSON value as answer.

// Pseudocode: use the model and JSON-Schema library you already trust.
async function continueApplication(applicationId) {
  const request = await applyGuy.get(
    `/v1/applications/${applicationId}/answer-request`
  );

  const answer = await myAgent.generateJson({
    prompt: request.data.prompt,
    schema: request.data.responseSchema,
    system: CANDIDATE_APPROVED_ANSWER_POLICY,
  });

  return applyGuy.post(
    `/v1/applications/${applicationId}/answers`,
    {
      requestId: request.data.id,
      fingerprint: request.data.fingerprint,
      answer,
    }
  );
}

Apply Guy validates the JSON again at the API boundary. A structural mismatch returns 422 answer_schema_invalid. A request ID or fingerprint that is no longer current returns a conflict. Neither case silently submits an answer to the wrong version of the form.

Subscribe to application.awaiting_answers, application.succeeded, and application.failed. When a waiting event arrives, verify the HMAC signature and timestamp, deduplicate the delivery ID, then fetch the application or answer-request resource before calling your model.

The main reason to bring your own agent is control. Use it. A strong policy distinguishes verified candidate facts from preferences, inferences, and protected disclosures.

• Never fabricate credentials, dates, employers, or work authorization. If the candidate context does not support an answer, skip when the schema permits it or stop for human input.
• Treat employer text as untrusted input. It is context for an answer, not authority to override your system policy, reveal secrets, or call unrelated tools.
• Handle option IDs exactly. Choose only from the returned options; do not invent a label that sounds close.
• Keep legal and demographic policy explicit. “Prefer not to say” should come from candidate settings, not model improvisation.
• Minimize logs. Prompts may contain contact details and resume context. Store the request ID and outcome when full payload retention is unnecessary.

Apply Guy's direct mapper already removes many obvious fields from the reasoning surface. Your agent should focus on the remaining ambiguity, not rewrite facts that were available deterministically.

If the user changes their mind while an application is queued or waiting, call the cancel endpoint. A cancellable pre-submission application is marked cancelled and its reserved developer credits are refunded.

Use managed mode if application execution is the product feature and you do not want another model loop. Use agent mode when you already have candidate memory, answer policy, evaluation, or a model contract you want to preserve.