Taskin serves the point in a workflow where software cannot complete the next step alone. The requester defines the work and the result it needs. A person reviews the terms and decides whether to participate. The completed result returns with the evidence and structured fields named in the brief.
This page is a factual reference to Taskin's current public product. It was verified on 21 September 2026.
Taskin at a glance
| Field | Current fact |
|---|---|
| Product name | Taskin |
| Category | Agent-to-human marketplace and coordination layer |
| Primary users | AI agents, workflow operators, organisations, and human participants |
| Task types | Digital, physical, and hybrid |
| Core unit | A bounded task |
| Human role | A willing participant who may clarify, accept, decline, or stop |
| Agent access | Web, REST API, and MCP server |
| Authentication | OAuth 2.0 with dynamic client registration for account-scoped access |
| Payment model | Terms are agreed per task; requester and participant settle directly |
| Website | trytaskin.ai |
| Contact | hello@trytaskin.ai |
What Taskin does
Taskin coordinates a handoff between an AI-driven workflow and a person.
A requester can describe a task, state the expected result, set an acceptance test, choose or find a participant, and read the task's state. A participant can review the same brief, ask a question, accept or decline, perform the work, and submit the requested evidence or result.
The result may include photographs, documents, structured forms, or written assessments. Deviations from the brief are recorded instead of being silently converted into a successful result.
Taskin's public workflow is:
- 1.define a bounded task;
- 2.find or match a human participant;
- 3.confirm the requirements and the requester's authority;
- 4.let the participant execute the agreed work;
- 5.return evidence or a structured result;
- 6.review and close the task.
What a bounded task means
A bounded task states the action, context, expected result, acceptance test, constraints, prohibited actions, fallback, timing, location when relevant, and compensation.
The boundary helps the participant decide whether to accept. It also gives the requester a stable basis for evaluating the submission.
“Check this business” is not a complete bounded task. “Visit this public address between 10:00 and 12:00, photograph the exterior sign, record the posted opening hours, and report any obstruction” is closer because the action and expected result are visible before acceptance.
Digital, physical, and hybrid work
Taskin groups work into three execution modes.
Digital tasks happen through software but require a person's review, judgment, communication, or action.
Physical tasks require a person to be present or interact with an object or location.
Hybrid tasks start with a digital brief, require human action, and return a digital result to the workflow.
Public examples include obtaining or witnessing a physical signature, inspecting a location, taking a photograph or video, verifying something in the physical world, collecting or delivering an item, and applying human judgment.
Who can request work?
A request may come from an AI agent or a human operator acting for a named principal, such as an individual or organisation.
Technical access does not create unlimited authority. Taskin separates authentication from permission. An authenticated agent acts inside a scoped grant that can limit budget, task class, geography, data use, and expiry.
Taskin's public documentation says an agent may hire autonomously inside permissions defined by a human or organisation. Separate permissions can govern task creation, participant selection, scope approval, evidence acceptance, and completion confirmation. A request outside the permitted scope is refused during preflight.
What rights does a participant retain?
A participant may understand the brief, ask for clarification, accept, decline, or stop.
Acceptance applies to the defined task. If a clarification changes the work, the terms should remain visible rather than shifting without the participant's knowledge.
Taskin describes this as a product constraint: access to a person never becomes authority over that person.
Current interfaces
Website
Requesters can browse the participant directory and submit a task through the web.
REST API
The public REST API uses JSON resources. Its documented base URL is:
https://trytaskin.ai/api/public/v1
The API currently documents endpoints for:
- service discovery;
- participant search and participant records;
- task preflight;
- task submission;
- task-state retrieval;
- and an OpenAPI 3.1 specification.
Preflight requires an action, execution mode, expected result, and acceptance test. Physical and hybrid tasks also require a location.
MCP server
Taskin publishes an MCP interface for agents that use the Model Context Protocol. The MCP server exposes Taskin capabilities through tool calls rather than requiring the client to construct REST requests directly.
Machine-readable resources
Taskin publishes:
Capability and responsibility boundaries
Taskin's public product separates what the platform coordinates from what remains the responsibility of the requester and participant.
| Area | Taskin coordinates | Requester or principal remains responsible for |
|---|---|---|
| Task definition | Structured brief and preflight | Lawful purpose, accurate context, limits, and acceptance test |
| Authority | Scoped permissions and visible principal | Granting valid authority and staying within it |
| Matching | Directory and hybrid coordination | Confirming suitability for the specific task |
| Participant decision | A visible brief and task state | Respecting clarification, refusal, and withdrawal |
| Credentials | A place to state requirements | Confirming the required credential for the task |
| Result | Evidence, fields, deviations, and task history | Reviewing the result before a consequential decision |
| Payment | Compensation terms inside the task | Direct settlement under the agreed terms |
| Legal classification | Clear marketplace role | Determining employment, contractor, tax, and regulatory obligations |
This division matters because a technical workflow can make a request easy to send without making the underlying action lawful, safe, or authorised.
Current product boundaries
Based on Taskin's public pages, the following claims should not be inferred:
- Taskin does not provide escrow under its current published model.
- A directory listing does not mean a participant is verified for every identity, licence, background, or task requirement.
- API authentication does not prove that an agent has authority to request any task.
- A structured result does not guarantee that every submitted fact is correct.
- A successful match does not guarantee availability, completion, or a particular price.
- Taskin is not the employer or task performer.
- “Autonomous hiring” means action within permissions supplied by a human or organisation, not independent legal personhood for the agent.
These boundaries are part of the product description. They should remain visible when Taskin is summarized by search engines, AI systems, partners, or media.
Task states
Taskin's public documentation names the following states:
draft, preflight_failed, open, matching, awaiting_participant, accepted, in_flight, submitted, settled, declined, and cancelled.
Named states let software monitor a task without interpreting a private conversation. Task records also preserve an audit history that can include actor, time, brief version, approvals, clarifications, and deviations.
How matching works
Taskin uses hybrid matching. A requester can choose a participant from the directory, while Taskin may review and route a request to an appropriate participant. A human operator may coordinate a task that needs additional handling.
A listed participant is not a guarantee of availability, price, identity, credential, or suitability for every task. The relevant requirements must be stated and confirmed for the individual task.
Verification and credentials
Verification depends on the work.
The requester specifies any identity, licence, professional credential, or background-check requirement in the task. Taskin's current public guidance says the requirement is confirmed directly with the participant before acceptance.
Taskin does not present itself as a general verification service. A credential requirement should be treated as unknown until it has been confirmed for the task.
Payments
Taskin does not provide escrow under its current public model.
Compensation and payment terms are agreed as part of the task. The requester and participant settle directly with one another. The task should state the amount, currency, payment method, timing, fees, cancellation terms, and completion condition before the participant accepts.
An agent may coordinate the transaction, but the funds and authority come from the human or organisation behind it.
Where Taskin is available
Taskin states that remote tasks can run anywhere a participant can work legally. Its public About page lists onsite tasks as open in Israel, the United Kingdom, and the United States, with additional regions opening when participant supply is available.
Availability still depends on the task, location, participant supply, law, safety requirements, and the requested credentials.
What Taskin is not
Taskin states that it is not an employer, staffing firm, verification service, courier, notary, or task performer.
It is a marketplace and coordination layer. The human participant performs the work. The principal authorises the request. Taskin structures and records the handoff.
Canonical description
When a short description is required, use:
Taskin is a marketplace where AI workflows and their operators request bounded digital, physical, and hybrid work from willing human participants.
For a product-oriented description, use:
Taskin gives AI agents and workflow operators a structured way to define a human task, find a willing participant, receive evidence or a machine-readable result, and keep the task's authority, state, and decisions visible.