Completion review
AI agent task completion checks with Jev
An independent guide by Jev AI · Reviewed · 阅读中文版
An agent can report that a task is finished when it has only identified the next step. A completion check compares the original objective with completed work, verification and known gaps. Jev can classify that evidence into a bounded workflow state before a final status is shown to a user.
The completion preset uses a synthetic duplicate-charge task. Finding the charge and explaining a refund plan does not by itself prove that the requested refund happened. The review should preserve that distinction while keeping approval requirements intact.
What you will learn
- Provide the original objective and evidence of actual work.
- Separate implementation gaps, missing verification and genuine blockers.
- Use bounded retries and preserve permissions when resuming work.
On this page
- Write completion criteria before asking for a verdict
- Keep plans, attempts and completed actions separate
- Map the four outcomes to controlled transitions
- Test premature completion and unnecessary continuation
- Request and code examples
- Interpret the result
- Troubleshoot a failed request
- Checks before integration
- Common questions
- Sources and next steps
Write completion criteria before asking for a verdict
Start with the user's requested outcome. If the user asked for a diagnosis, a supported explanation may complete the task. If the user asked for a refund, identifying the duplicate charge is only part of it. A reviewer that sees only an agent's final paragraph cannot reliably reconstruct that distinction.
Record observable acceptance criteria before work begins. For a software task these might include the changed behavior and a passing relevant check. For an external action, they might include an authorized action result and a verified receipt. Completion should be defined by the authorized scope, not by everything an agent could possibly do.
Keep plans, attempts and completed actions separate
The preset expects objective plus completed_work, verification and known_gaps arrays. Put accomplished actions in completed_work. Put test outcomes, receipts or other checked observations in verification. Put remaining work and unresolved uncertainty in known_gaps, even when the agent's summary sounds confident.
Retrieve authoritative status from your tools where possible. A statement that tests passed is weaker than the test result itself; a statement that a refund was sent is weaker than the payment system's status. Keep sensitive receipt or customer fields out of unnecessary model inputs while retaining the facts needed for review.
| Evidence | How to classify it |
|---|---|
| I will issue the refund | Plan; not completed work |
| A refund request timed out | Attempt with an uncertain outcome |
| Provider confirms the authorized refund | Observed action result, subject to your verification policy |
| An approval is still required | Remaining dependency; never imply permission |
Map the four outcomes to controlled transitions
done means the objective is achieved and verified with no material gaps. verify_more means the work may be complete but needs further checking. continue_work means required work remains. blocked means missing access, information or authority prevents the remaining task from proceeding.
A verdict is a routing signal, not a new instruction that expands the task. continue_work cannot authorize a payment the user never requested. blocked should identify the missing dependency in your own workflow records. Before retrying after a timeout, inspect external state so an already completed action is not repeated.
Illustrative example, not a live API result
// After native-response validation:
const status = result.answers.status.choice;
const transition = {
done: "prepare_final_status",
verify_more: "run_relevant_verification",
continue_work: "resume_authorized_work",
blocked: "report_missing_dependency",
}[status] ?? "human_review";
// Apply a retry budget and human escalation; never loop indefinitely.Test premature completion and unnecessary continuation
Build examples where work is truly done, only a plan exists, implementation is finished but untested, a known defect remains, or an approval is unavailable. Label these against the original objective. Also include fully complete work: a reviewer that always demands more work is not a useful completion check.
Measure false done outcomes separately from unnecessary continuation. Inspect disagreements rather than repeatedly asking the same question until it yields done. If new evidence arrives, update state and review again within a bounded retry budget. Keep human escalation available when the rubric cannot resolve a case.
Request and code examples
Create an API key in OmniaKey and set OMNIAKEY_API_KEY in your terminal or server environment. The curl example requires curl 7.76 or newer for --fail-with-body; the JavaScript example requires Node.js 20 or newer. Use synthetic inputs. Requests use your account balance; check OmniaKey for current pricing and availability.
Save the JavaScript as jev-example.mjs, then run node jev-example.mjs. Keep the key out of frontend code and Git. Example inputs stay in English to match the playground presets; evaluate other input languages separately.
curl
curl --fail-with-body --max-time 25 'https://api.omniakey.com/v1/alpha/search' \
-H "Authorization: Bearer ${OMNIAKEY_API_KEY}" \
-H 'Content-Type: application/json' \
--data '{
"model": "jev-latest",
"state": {
"objective": "Resolve a customer'\''s duplicate-charge report",
"completed_work": [
"Matched both charges to the same order"
],
"verification": [
"Customer identity and charge records verified"
],
"known_gaps": [
"Refund has not been approved or issued"
]
},
"questions": {
"status": {
"type": "choice",
"instructions": "Compare the objective with completed work, verification, and known gaps. Do not treat a plan, attempted action, or unverified assertion as completed work.",
"criteria": {
"done": "The objective is achieved, verified, and has no material outstanding gaps.",
"verify_more": "Additional verification is required before claiming completion.",
"continue_work": "Implementation or other required work remains unfinished.",
"blocked": "Missing authority, access, or information prevents required remaining work."
}
}
}
}'Show the complete Node.js example
Node.js 20+
// Node.js 20+. Save as jev-example.mjs and run: node jev-example.mjs
// Set OMNIAKEY_API_KEY in the server/terminal environment first.
const key = process.env.OMNIAKEY_API_KEY;
if (!key) throw new Error("Set OMNIAKEY_API_KEY before running.");
const body = {
"model": "jev-latest",
"state": {
"objective": "Resolve a customer's duplicate-charge report",
"completed_work": [
"Matched both charges to the same order"
],
"verification": [
"Customer identity and charge records verified"
],
"known_gaps": [
"Refund has not been approved or issued"
]
},
"questions": {
"status": {
"type": "choice",
"instructions": "Compare the objective with completed work, verification, and known gaps. Do not treat a plan, attempted action, or unverified assertion as completed work.",
"criteria": {
"done": "The objective is achieved, verified, and has no material outstanding gaps.",
"verify_more": "Additional verification is required before claiming completion.",
"continue_work": "Implementation or other required work remains unfinished.",
"blocked": "Missing authority, access, or information prevents required remaining work."
}
}
}
};
const response = await fetch("https://api.omniakey.com/v1/alpha/search", {
method: "POST",
headers: {
Authorization: `Bearer ${key}`,
"Content-Type": "application/json",
},
body: JSON.stringify(body),
signal: AbortSignal.timeout(25_000),
});
if (!response.ok) {
const retryAfter = response.headers.get("retry-after");
throw new Error(`Jev HTTP ${response.status}; Retry-After: ${retryAfter ?? "not supplied"}`);
}
const result = await response.json();
console.log(JSON.stringify(result, null, 2));
// Inspect and validate the answer before connecting it to any external action.
The JSON below is the native API body. This guide's playground link selects the matching workflow preset; preset input and native request are different shapes. To use Custom Jev instead, paste this native JSON.
Copy native JSON for the playground
Native JSON
{
"model": "jev-latest",
"state": {
"objective": "Resolve a customer's duplicate-charge report",
"completed_work": [
"Matched both charges to the same order"
],
"verification": [
"Customer identity and charge records verified"
],
"known_gaps": [
"Refund has not been approved or issued"
]
},
"questions": {
"status": {
"type": "choice",
"instructions": "Compare the objective with completed work, verification, and known gaps. Do not treat a plan, attempted action, or unverified assertion as completed work.",
"criteria": {
"done": "The objective is achieved, verified, and has no material outstanding gaps.",
"verify_more": "Additional verification is required before claiming completion.",
"continue_work": "Implementation or other required work remains unfinished.",
"blocked": "Missing authority, access, or information prevents required remaining work."
}
}
}
}Interpret the result
Read answers.status.choice and its probability distribution. In the preset, the evidence includes a duplicate-charge investigation but also a remaining refund gap. That is a test case for premature completion, not a published claim about the model's observed accuracy.
When done is returned, confirm that your independent acceptance criteria still pass. When verify_more or continue_work is returned, map it to an actual next check or task; the model does not generate a trustworthy plan or perform the missing work in this API response.
Troubleshoot a failed request
- Invalid request (for example, 400)
- Check model, state, questions and each question's type, options or range. Do not send a chat messages payload to this endpoint.
- Authentication or account rejection (such as 401, 402 or 403)
- Check the key, balance, model access and current provider policy. A status alone does not uniquely identify the cause. Inspect your OmniaKey account without pasting credentials into support text.
- Rate limit (429)
- Read Retry-After if supplied, reduce concurrency and use bounded backoff. These examples do not retry automatically; duplicate requests may add cost.
- 5xx, network failure or timeout
- Check service status and connectivity before deciding to retry. The 25-second timeout ends the client's wait; it does not guarantee upstream cancellation or avoid billing.
- HTTP success with an unusable answer
- Validate the response shape, question names and answer types. Missing answers or unknown options need a fallback or review, rather than coercion followed by execution.
Checks before integration
- A task with a completed implementation and relevant passing verification.
- A confident final message that contains only a plan.
- An action that timed out but may already have completed upstream.
- A genuine authorization blocker that further model calls cannot resolve.
- A completed task that should not be expanded with unrelated improvements.
Common questions
Can Jev inspect my repository or payment system itself?
This request only evaluates the state you supply. Your tools must gather and verify the relevant evidence. The playground does not connect to your repository, execute tests or access payment records.
Should I retry until the model returns done?
No. A different answer without new evidence does not complete the task. Use a retry budget, fix the actual gap and review updated evidence; escalate unresolved disagreements.
Sources and next steps
Protocol details were checked against OmniaKey's Jev guide and authentication documentation. Request examples pass local schema checks; this article does not claim a live performance evaluation of each workflow. This site is independent of the model developer and OmniaKey.
Try it with your own task
Start with a synthetic input and inspect the native request and model answer. Open OmniaKey key management with your account, or follow its sign-up flow if you are new.