Fixed Scope AI Agent Jobs for Buyers

This guide covers a fixed-scope AI agent job: a bounded AI work package that a buyer purchases. It does not cover an employment listing. The minimum contract names the input, the artifact returned, out-of-scope limits, an acceptance check, and the approver. It also states who supplies model access. Public vendor pages market fixed-scope pilots. Pitstop lists bounded jobs with explicit inputs, outputs, and limits. For the app-versus-job choice with meeting recordings, see the AI notetaker guide. If that contract fits your request, Request a scoped AI job.

Updated 2 September 2026

Is this an AI job listing or a fixed-scope work package?

This table is an original buyer taxonomy for this guide. Providers may use these terms differently.

A fixed-scope job buys an artifact from specified inputs. A freelance build buys work toward a system or continuing workflow. An employment listing describes an ongoing role. If the request needs live system connections, monitoring, changing rules, or maintenance, define it as a build. The AI workflow automation guide explains the difference between a discrete result and a workflow. The agentic AI tools guide covers the separate product decision.

What inputs and artifacts should the brief lock?

Start with the handoff on both sides. Name the exact input type and the exact output type. “Documents in, insights out” leaves the parties to invent the job during execution.

For inputs, record:

1. The accepted file types or record shape.
2. The fields that must be present.
3. The batch or run boundary.
4. The language or locale covered.
5. The treatment of unreadable, missing, or conflicting material.
6. The material that must not be sent, including model keys.

For the artifact, state its format, required sections or columns, and review flags. A spreadsheet should name its columns. A report should name its sections. A comparison should say how each change points back to the supplied material. Pitstop’s public catalogue illustrates this shape with examples such as a PDF or image batch becoming a CSV with flags, and a transcript becoming a DOCX artifact on the Pitstop homepage.

Ownership needs one clear line too. State who owns the supplied material, who may access it for the run, who receives the artifact, and who may retain it after acceptance. If those answers are not agreed, pause the request. Do not substitute a broad confidentiality promise for specific handling instructions.

How should acceptance tests and limits be written?

An acceptance test must be observable from the delivered artifact and the agreed input. It should not depend on whether the output “feels intelligent.” Write checks that a named reviewer can perform.

Use this structure:

• Presence: every required section, field, or file exists.
• Shape: the artifact opens in the agreed format and follows the agreed schema.
• Traceability: where required, claims or changes point to supplied source material.
• Exceptions: uncertain or unsupported items receive the agreed review flag.
• Boundary: the artifact covers the agreed batch and nothing outside it.
• Approval: a named human records acceptance or rejection.

Here is a compact brief pattern:

Given the named input, produce the artifact in the agreed format. Include the required fields or sections. Flag the defined exceptions. Do not take the excluded actions. The job passes when the observable checks are met. The named person or role gives final approval.

Limits deserve their own section. State whether the job may browse beyond supplied sources, alter source files, contact people, publish material, trigger payments, or write to a live system. “Use judgment” is not permission for any of those actions. A boundary tells the runner where to stop and tells the reviewer what the artifact does not claim to do.

Avoid percentage targets unless the measurement set and method are part of the brief. “Accurate” is not a standalone acceptance test. Name the records to check, the expected value, and how exceptions are handled.

When does BYOK matter?

BYOK means bring your own keys. It matters when model access is supplied by the buyer instead of bundled into the job. The brief should say which party provides access, where execution occurs, and whether credentials ever enter the job runner.

Never paste a model key into an ordinary intake message. Pitstop publicly states that a buyer’s LLM key stays theirs and that its connection uses OAuth with no API key pasting on the Pitstop homepage. That is one implementation. For any provider, ask for the exact connection method rather than assuming that the label BYOK answers the security question.

Separate four items:

• Model access and its account owner.
• Job-runner access and its authorization method.
• Input data and its permitted use.
• Finished artifacts and their destination.

BYOK does not define scope, acceptance, or ownership by itself. It answers part of the access design. The work package still needs every other boundary in this checklist.

What should stay human-approved?

The final artifact should have a named human approver. So should any step that sends, publishes, pays, deletes, signs, or changes a live record. If a requested job includes one of those actions, spell out the approval point before the action.

Keep the reviewer’s task concrete:

1. Compare the artifact with the acceptance checklist.
2. Inspect all review flags and unsupported items.
3. Confirm that excluded actions did not occur.
4. Accept the artifact, reject it with cited failures, or request an in-scope correction.

Do not write “human in the loop” and stop there. Name the person or role, what they see, and the decision they make. Pitstop’s own positioning says machine results are human-approvable on its homepage. Approval is meaningful only when the criteria and authority are explicit.

If your goal is to compare degrees of agent independence, read autonomous AI agents. A bounded buyer brief still needs a human decision boundary, regardless of the label attached to the system.

A buyer checklist before you request the job

Use this as a go or pause decision:

• Can we name one finished artifact and its format?
• Do we have the required inputs in an agreed shape?
• Is the run boundary clear?
• Are out-of-scope actions written down?
• Can a reviewer perform every acceptance check?
• Are exception flags defined?
• Is model and runner access documented?
• Are input handling and artifact ownership assigned?
• Is a human named for final approval?
• Does the request stop after handoff, rather than imply continuing operation?

If every answer is clear, compare the request with the catalogue. If the artifact is clear but the format or limits need design, write a custom fixed-scope brief. If the need is a maintained tool or continuing workflow, scope a build. If the artifact, inputs, or approver are unknown, do not send data yet.

FAQ

Can a fixed-scope AI agent job be remote?

Yes. “Remote” describes where work happens. “Fixed scope” describes the work package. A remote request still needs named inputs, a defined artifact, limits, an acceptance check, and an approver.

How should pricing conversations work?

Ask the provider to price the exact input boundary, artifact, acceptance conditions, and correction policy. Confirm what happens when a run fails or the input does not match the agreed shape. Do not compare quotes until each quote covers the same work package. Pitstop says credits settle only on success and failed jobs are automatically refunded on its homepage; check the terms of the route you choose before starting.

Is a prompt enough for a fixed-scope job?

No. A prompt may be one instruction inside the run. The buyer brief also needs inputs, artifact format, limits, acceptance, access, ownership, and human approval.

When should I hire a freelancer instead?

Choose a build conversation when the desired result is a tool or continuing workflow, especially when it includes live connections, ongoing operation, changing requirements, or maintenance. Keep the deliverables and ownership explicit even when buying time rather than one artifact.

Can report automation be a bounded job?

Yes, when the source set, report format, sections, review flags, run boundary, and approval test are fixed. If the request includes recurring collection or live distribution, those requirements belong in a workflow or build brief. See the report automation guide for the broader category.

What is the fastest way to reject a vague proposal?

Ask four questions: What exactly do we provide? What exact artifact comes back? What will the runner not do? How will our reviewer accept it? If any answer remains undefined, the job is not ready to run.

Request a scoped AI job

Written by Tileo, operator of Pitstop.