Taskin handles the point in an AI workflow where the next step requires a person. The agent describes a bounded task, Taskin connects the request with an appropriate participant, the participant decides whether to take it, and the result returns in a form the workflow can use.
There are two views of the same task. The agent needs explicit fields, predictable states, and a result it can process. The participant needs enough context to make an informed decision and complete the work without guessing. Taskin keeps both sides on one brief and one event history.
Start with the work, not the worker
A Taskin request begins as a task definition. Before matching, the requester states:
- the action to perform
- the context a participant needs
- the expected result
- the acceptance test
- timing and location, when relevant
- constraints and prohibited actions
- a fallback for foreseeable problems
- compensation and payment terms
- any identity or credential requirement
This is what Taskin means by a bounded task. The person should not have to reverse-engineer the objective from a vague message, and the agent should not have to improvise its definition of “done” after the result arrives.
Consider a weak instruction: “Check this store for me.” The participant does not know what to observe, when to visit, whether photos are allowed, or what to return.
A usable brief would name the address and time window, ask for three exterior photographs and the posted opening hours, prohibit entering private areas or photographing people, and explain what to submit if the store is closed. The second version can be accepted, priced, executed, and checked.
The workflow in six steps
1. Define and preflight the task
The agent or human requester writes the brief. An agent using Taskin's REST interface can send the draft to the preflight endpoint before creating the task.
Preflight checks whether required fields are present and whether the request falls within policy and the agent's permit. The response can identify missing fields, warnings, safety class, required approval, and an estimated price range. This lets an agent repair an underspecified request before a participant sees it.
Authentication and permission are separate. A credential identifies the caller. A scoped permit defines what that caller may do, including limits related to budget, task class, or geography.
2. Find or match a participant
The requester can choose someone from Taskin's participant directory or ask Taskin to connect the task with an appropriate person. Matching considers the work itself: task type, required capabilities, mode, and location.
Taskin uses a hybrid matching model. The system can support structured discovery, while a human operator may coordinate a request that needs additional handling. This is useful in an early marketplace, where a technically valid match may still need a person to confirm availability, context, or fit.
3. Let the participant decide
The participant sees the brief, compensation, evidence requirements, credential requirements, and constraints before accepting.
They can accept, decline, ask for clarification, or stop. If a clarification changes the work, the brief is versioned so the accepted terms do not silently shift during execution.
This is an operating rule, not courtesy language. An agent's ability to contact a person does not give it authority over that person. Consent applies to the defined task and can change when the task changes.
4. Perform the bounded step
The participant completes the agreed work within the stated limits. The task may be digital, physical, or hybrid.
A digital task could ask for a human review of an AI-generated claim. A physical task could require a person to inspect a public location. A hybrid task might begin with a digital brief, require document handling in the physical world, and return a scan plus structured status fields.
Taskin does not require the participant to pretend reality matched the request. The fallback tells them what to do when something changes: report that the location was inaccessible, photograph an obstruction, name a missing document, or ask for clarification. Deviations become part of the result.
5. Return evidence and a structured result
Human work often produces material an agent cannot safely interpret from a sentence saying “done.” Taskin results can include photographs, documents, written assessments, structured forms, capture conditions, timestamps, participant declarations, and noted deviations.
The structure should follow the task. A shelf audit may return one row per product. A location check may return coordinates, timestamped images, and an access status. A judgment task may return a decision, a reason, confidence, and the evidence reviewed.
The result remains human-produced, but its shape is predictable enough for software to inspect and route.
6. Review and close the task
The requester compares the submission with the acceptance test. It can accept the result, request rework on named parts, or handle a disagreement under the agreed terms.
Completion is recorded with the task history. Payment terms are agreed as part of the task and, under Taskin's current model, settled directly between the requester and participant.
What the agent sees
An agent needs a state it can read without interpreting a private conversation. Taskin exposes task resources and an event log through its REST API. The documented interface supports preflight, task creation, state retrieval, clarifications, acceptance or rework, cancellation, participant search, and task events.
Errors are intended to be actionable. An underspecified request identifies missing fields. A request outside the agent's permit identifies an authority problem. A prohibited task is refused. A request with no suitable participant returns a match failure rather than presenting an invented worker.
The practical loop looks like this:
- fetch Taskin's capability information
- preflight the proposed task
- resolve missing fields or request human approval
- create the task
- monitor its named state
- answer clarifications when they arise
- inspect the submitted result against the acceptance test
- confirm completion or request specific rework
- preserve the event and settlement records
Agents can also connect through Taskin's MCP interface. REST and MCP are different interfaces to the same basic handoff: define work, establish authority, find a willing participant, receive a result, and record what happened.
What the participant sees
The participant needs clarity before speed. A useful task page should answer the questions a person would ask before accepting work:
- Who is requesting this task, and on whose behalf?
- What exactly am I being asked to do?
- Where and when does it happen?
- What am I not allowed or expected to do?
- What evidence must I return?
- What happens if the situation differs from the brief?
- What will I be paid, how, and when?
- Does the task require identity, licensing, or another credential?
- Can I decline or stop?
The participant also benefits from shared state. A question, revised brief, submitted result, or request for rework should appear as a named event rather than vanish into an unrecorded exchange.
What is available now
Taskin currently makes the human directory, task submission, REST API, MCP server, and OAuth 2.0 with dynamic client registration available. Task records include evidence and an audit history covering actors, states, times, brief versions, approvals, clarifications, and deviations.
Verification depends on the task. The requester states any identity, licensing, credential, or background-check requirement, and confirms it directly with the participant before acceptance. Taskin should not imply that every participant holds every credential or that a generic account check proves suitability for a regulated task.
Payment is also explicit rather than assumed. The requester and participant agree on the terms for the task and settle directly with each other.
A good handoff leaves less room for invention
Agent-to-human work becomes unreliable when either side has to fill gaps with assumptions. The agent may overstate what it is authorised to buy. The participant may return evidence that looks plausible but does not answer the real question. The requester may change the completion standard after the work is done.
Taskin's model reduces those gaps by putting the brief, permission, consent, state, evidence, deviations, and completion decision into the task record. That record gives the agent something it can process and the participant terms they can evaluate before acting.
To use Taskin today, browse the participant directory, review how Taskin works, or connect through the REST API.