Skip to content
Pyrana
For business leaders
Digital workers
Agent governance

Digital workers need a manager, not a chatbot

An agent needs what a new hire needs on day one: an identity, scoped access, a spending limit, an approver, a reviewer, and a record. Most companies gave it a chat window instead. Here is the job description for your first digital worker.

Eric Tarnowski
September 9, 2026
7 min read

Somebody deployed an agent

Somewhere in your company, a team has "deployed an AI agent." Go look at it. Most of the time it is a chat window. It answers questions about documents. Either it cannot do anything in your systems, or it can do everything, because it runs on the credentials of the person who built it. Both versions get a demo. Neither has a job.

Forrester's June 2026 survey found that three quarters of enterprise leaders say they are adopting agentic AI, and that only a small minority have anything in production beyond what Forrester calls "agentish" chatbots. I think the reason is a mental-model problem, and the fix is older than AI.

The application is the job. The agent is the worker.

When you hire a person into finance, you do not hand them a laptop and say "help." You give them a job: close the books for Business Unit A. You give them a place to do it: the ledger, the sub-ledgers, the close checklist, the folder of policies. You give them rules: post entries below 25,000 USD, bring anything above that to the controller, never touch payroll. And you give them a manager, whose actual work in week one is mundane. Get them a login. Request the right access and only that. Set their approval authority. Review their first month. Make sure everything they do leaves a record.

That is what an agent needs, and it is what chatbot-shaped deployments skip. The chatbot has no job, so it has no rules. It has no identity of its own, so its access is whatever its builder had. Nobody reviews its work, because no work was defined. There is no record, because nothing was designed to produce one.

So the model I use is this. The application is the job, the rules, and the workplace. The agent is a digital worker inside it. The platform does what a manager does: access, limits, approvals, review, and a record. When a board asks for "governance for agents," that sentence is the whole of what it means.

What happens without the manager

The data on how companies treat agents today reads like an HR audit gone wrong.

Seventy percent of organizations report that AI systems are granted higher levels of privileged access than a human would need to do the same task (Teleport, Infrastructure Identity Survey 2026, February 2026). Fewer than half of CISOs, 47 percent, are confident they can identify every agent in their environment, and 46 percent say they control what those agents interact with (Okta, Global CISO Insights 2026, July 2026). Only 21 percent of organizations have a mature governance model for agentic AI, and the missing pieces Deloitte lists are boundaries between what an agent may decide alone and what needs a person, monitoring of what agents are doing, and audit trails of what they did (Deloitte, April 2026).

Gartner's May 2026 finding is the one I would put in front of a CEO. Enterprises are treating agent governance as binary, either locked down or fully trusted, and Gartner calls that the root cause of failure; the remedy is governance tiered by how much autonomy an agent actually has. Nobody would give a new analyst either the CFO's signing authority or no login at all. We do both to agents, routinely.

Forrester's recommendation is the manager's checklist written for machines: treat every agent as a governed identity with unique credentials, least privilege, full logging, and a named owner. Every item on that list is a thing a manager does for a new hire.

Two ways a digital worker works

A digital worker has two modes, and a good application supports both.

In the background. A monthly close App for a manufacturer with three business units starts at 2:00 a.m. on the second business day. The worker reconciles intercompany balances, drafts accruals from open POs, and posts what falls inside its authority: 212 entries, all below the 25,000 USD threshold. It cannot post the rest. A 41,800 USD reclass goes to the controller. An intercompany mismatch between Unit A and Unit B goes to Unit B's controller because the policy says that decision is hers. By 7:40 a.m. each controller has a short list of exceptions with the evidence attached, rather than a blank ledger and a checklist.

Alongside a person. A buyer at a PE-backed hospitality group is assembling a request for 40 laptops, 18,500 USD, in the procurement App. The worker sits in the same App. It fills in the contracted vendor and price, checks the budget line, attaches the quotes, and flags that the request exceeds her 15,000 USD authority and will need her director. She submits. The director approves in the lane the policy names, the PO is raised, and the record shows who did which part. The policy was applied as she went, by a worker that has read the procurement policy and is in the same room. She never left the App to ask a chatbot.

Both are the same worker under the same manager: one identity, one set of limits, one record.

Writing the job description

Whatever you buy or build, the job description for a digital worker has the same lines a human one has, and each line has to resolve to a mechanism you can point at.

The job is a named process with a start, an end, and a measure. The workplace is the list of systems and data slices the worker may touch, and nothing else. The identity is the worker's own, in your identity provider and in each system it reaches. The authority is what it may do alone, with the thresholds written down. The approver is a named person or group for everything above the authority, in a lane that keeps a record. The reviewer is whoever reads the record and how often. And the record itself is one place where every action, approved or refused, is written.

If a vendor cannot show you where each line lives in their product, the worker has no manager. It has a chat window.

How we handle this at Pyrana

An Agentic App on Pyrana is the job and the workplace. It is defined as configuration, compiled into an immutable version, and activated by moving one pointer. Agents belong to Apps and inherit the App's rules and nothing more.

Every call into the App passes the same admission check whether a person makes it from the App's UI, a person asks in chat, a system calls the API, another agent calls over MCP, or a schedule fires at 2:00 a.m.: who is calling, under what authority, on which data, with what approval. It fails closed, and the audit record is written before anything runs.

Access is one grant. An access profile correlates what a caller may do with which slice of data, so "reviewer in Business Unit A" is a single grant rather than a role and a filter that someone has to keep in sync. Every caller keeps its real identity through every door: a person via SSO, a workflow as its own principal, an agent acting for a person via a delegated token. A child call can never exceed its parent's authority, so an agent working for the buyer in chat can do what she can do, minus what the App restricts, and never more.

Agents hold their own identity and credentials, inside the platform and in the systems they touch. The close worker has its own credentials for SharePoint site A, where the close workpapers live. The procurement worker has its own for site B, where the contracts live. Neither can list the other's files, and when the close worker is asked about a contract, the answer is that nothing was found. Unauthorized items are absent from results rather than "denied," so a worker cannot learn what exists by being refused.

Approval is a policy over typed arguments. We built conditional approval so that above a threshold the invocation, its arguments, and its evidence are frozen where the worker cannot change them; each named approval lane (the requesting user, the finance group, the admins) gets its own obligation; the reviewer's eligibility is checked at decision time, so a director whose group membership was revoked yesterday cannot approve today; and the frozen invocation is revalidated before it dispatches once. This is built and enabled per App.

The record is one AppExecution per call, whichever door it came through: who called, under what authority, which App version ran, what happened, and which context was retrieved, injected into the prompt, and cited, with the Context Units (CxUs) from cortIQ named by their content hash. That is the reviewer's line in the job description, and it exists before the worker does anything.

What is next for us is the registry of published outputs, so that the close worker's approved report has a stable name any authorized App can cite later. Today that sharing happens through cortIQ context and App configuration.

Your first digital worker

Next week, write one page. Name the process and its cycle time today. List the systems it touches. Name the identity the worker will have in each one. Write down what it may do alone and the thresholds. Name the approver and the reviewer. Then hand that page to whoever is selling you an agent and ask them to show you each line as a mechanism, and to show you the record of one call the worker was refused.

If they can only show you a chat window, you have found a chatbot.

Sources

Continue the Conversation

Building production-grade agentic AI requires context, orchestration, and human-in-the-loop design. We'd love to show you how Pyrana delivers it end to end.

Request a Demo