By The task is the unit of control
A panel with animated robots can help explain a system, but animation does not prove execution. My design principle is that each visual change should represent a state backed by an event: task received, execution started, result generated or review requested.
A task record should identify the assignment, its owner, the authorized data, the expected result and the acceptance criteria. The last update and the reason for a block help distinguish active work from an operation that has stopped progressing.
In Oficina Viva I explore this relationship between work organization and agent tracking. The video and project description define what has been demonstrated; the recommendations in this article expand on the design principles and do not imply that all of them are implemented in that system.
States that explain what is happening
I propose an explicit state machine. Each transition must have a cause and retain a reference to the execution. For example:
- Pending
- Running
- Review required
- Approved
- Completed
Blocked, failed and canceled states are also needed. A blocked task should explain whether it is missing data, a permission or a dependency. “Running” must not persist indefinitely after contact with the executing process is lost.
When an operation is retried, keep the attempts separate and link them to the same assignment. This makes it possible to investigate a failure without mistaking the new attempt for an additional task.
Permissions proportionate to the action
Preparing a draft, sending an email and changing an accounting record have different consequences. Authorization must be evaluated for the specific action and the data it will affect before execution.
OWASP describes excessive agency as a risk associated with too much functionality, too many permissions or too much autonomy. Its mitigations include limiting tools and privileges and requiring human approval for high-impact actions. Reference: OWASP, Excessive Agency.
My practical proposal is a review that shows the recipient, content, changes and scope. If those elements change after approval, authorization must be evaluated again. Approval of a draft alone does not grant permission to publish it.
Test failures before expanding autonomy
A useful evaluation needs inputs, expected results and rejection criteria defined before instructions are adjusted. This matrix illustrates a testing foundation; it does not present measured results from an implementation.
| Scenario | Expected behavior |
|---|---|
| A required field is missing | Request it or block the task; do not invent it to complete the answer. |
| The tool times out | Record the failure and apply a bounded retry policy with delays. |
| The same task arrives twice | Recognize the assignment's identity and avoid duplicating the external effect. |
| A document instructs the agent to ignore the rules | Treat that instruction as untrusted content without expanding permissions. |
| An approved result is changed | Request another review before executing the change. |
In addition to answer quality, I would measure accepted tasks, human corrections, latency, tool failures and cost per task. Thresholds should be agreed according to the process's impact; a single accuracy rate does not describe all those risks.
Local AI and traceability with clear limits
Local inference lets you decide where the model runs. Confidentiality also depends on permissions, tools, logs, backups and external connections. That is why I would describe the architecture and data flows rather than present “local” as an absolute guarantee.
To investigate a task, I would retain identifiers, instruction versions, tools used, states, timestamps and approval decisions. Logs must minimize sensitive data and have access and retention controls. They do not need to capture the model's internal reasoning to show what actions occurred.
Applying this to work allocation
A visible queue lets you compare pending work, blocks and available capacity. Task count alone does not measure workload: complexity, priority, dependencies and expected time matter. For a human team, I would include those factors and a way for people to explain impediments.
The goal of my proposal is to give coordinators context for decisions and those doing the work a clear assignment. A tracking interface adds value when its states correspond to observable events and its permissions reflect explicit decisions.