A defined deployment boundary
The runtime and persistent working memory operate inside the environment selected for the engagement.
How Workers operate
Where your data goes—and who decides.
See the deployment boundary, approved model and tool paths, human-readable working memory, approval ownership, testing, and supervision behind a managed AI Worker.
The exact operating map is confirmed for each deployment.
Direct answer
How does a Worker operate?
Each Worker deployment has an agreed environment, an approved model endpoint, defined tool and communication connections, human-readable working memory, named approval owners, and an escalation path. The exact providers, regions, retention terms, access rules, subprocessors, and contractual requirements are confirmed before deployment.
Approved processing paths
Task data may move through the approved model, tool, communication, and support paths required by the workflow.
Named human ownership
Approval owners and escalation rules are mapped before launch, then reviewed as the workflow changes.
The stack
Six parts, one Worker.
A Worker is a managed operating system for one defined job—not a model acting alone. The deployment environment, runtime, connections, memory, communication, and supervision work together.
Environment selected for the deployment
Workers Harness
orient → plan → act → verify → record
Working memory
readable context and activity history
External dependencies
Approved model endpoint
provider and terms confirmed
Approved business tools
scoped connections
Communication paths
inputs, outputs, and escalation
Approval owner
reviews the actions mapped for a person
Compute
Deployment environment
An isolated environment is configured for the engagement. Its provider, region, tenancy model, and access boundary are documented for that deployment.
Runtime
Workers Harness
The managed runtime orients to the workflow, plans a bounded step, uses an approved connection, records the result, and continues according to the operating rules.
Tools
Connection layer
Each business-system connection has an agreed purpose, permission scope, owner, and revocation path. Authentication material is handled separately from worker-authored memory.
Memory
Readable working memory
Human-readable notes inside the selected environment hold the Worker’s role, active tasks, durable context, and activity history for the configured workflow.
Communication
Workflow channels
Approved channels carry inputs, outputs, approval requests, and escalations. The channel may be email, chat, or another system selected for the engagement.
Supervision
People and support
Designated client owners supervise business decisions. Taurist monitors and maintains the Worker within the agreed support scope, with responsibilities mapped before launch.
Infrastructure
The deployment profile is agreed, not assumed.
Environment, provider, processing, access, continuity, and recordkeeping choices vary with the engagement. The operating map makes those choices explicit before launch.
What the environment provides
| Deployment boundary | An isolated environment configured for the engagement. The exact topology and tenancy model are documented before launch. |
|---|---|
| Runtime profile | Linux, browser access, and other runtime tools are included where the approved workflow requires them. |
| Sizing | Compute, memory, and storage are matched to the expected workload and adjusted through the engagement when needed. |
| Continuity | Persistent working state can support restarts. Availability, backup, and recovery targets are deployment-specific and must be confirmed in scope. |
| Hosting region | Hosting and processing regions are confirmed before deployment, including the regions used by approved external services where relevant. |
| Tenancy | The tenancy model for compute, storage, model access, and connected tools is documented for the selected providers. |
How access and records are handled
| Data protection | In-transit and at-rest protections are provided or configured through the selected environment and services, then confirmed for the deployment. |
|---|---|
| Data paths | The environment, approved model endpoint, business tools, communication channels, and support paths are mapped for the workflow. |
| Credentials | Authentication material is handled separately from worker-authored memory. Storage, injection, rotation, and visibility depend on the selected environment and connection. |
| Support access | Taurist maintenance access, client administrative access, and provider responsibilities are documented for the deployment. |
| Network access | Outbound paths and any allow-listing are configured according to the environment and the services the workflow needs. |
| Tool permissions | Permission scope, approval ownership, and revocation are defined connection by connection and tested or documented before launch. |
| Records | The client can inspect human-readable working memory and activity history. Any formal logging, evidence, or audit requirement is agreed separately. |
Anatomy of a Worker
Who it is, written down.
The charter turns a general AI capability into an operating role for one recurring workflow. It records the role, working-memory rules, approved paths, approval ownership, and escalation expectations.
Worker charter
- 01
Identity
Who the Worker is, the defined job it performs, and who owns that workflow.
- 02
Memory rules
What context the Worker reads before acting and what it records after a task step.
- 03
Operating loop
How it orients, plans, acts, verifies, records, and returns to the next bounded step.
- 04
Tools
Which approved connections the workflow may use and what each connection is for.
- 05
Escalation
Which conditions should pause the task and who receives the question or exception.
- 06
Approval and guardrails
Which actions require a designated person before the workflow proceeds.
The charter records the Worker’s standing operating instructions. It is one layer of the operating boundary; environment controls, tool permissions, and provider settings are defined separately.
One Worker handles one defined job.
A Worker is not positioned as a general-purpose employee replacement. It handles a mapped workflow while named people, checks, connected systems, and support responsibilities remain around it.
- A recurring job with a clear owner
- Known inputs, outputs, and exclusions
- Mapped approvals and escalation paths
- 01
Orient
Read the role, current task, and relevant working memory.
- 02
Plan
Choose the next bounded step inside the mapped workflow.
- 03
Act
Use the approved model or tool path needed for that step.
- 04
Verify
Check the result against the task, rules, and available evidence.
- 05
Record
Update working memory and activity history, then continue or escalate.
Update working memory, then return to the next bounded step or escalation.
Memory
The vault is human-readable working memory.
Plain-text structure makes the Worker’s role and maintained context practical to inspect. The access, correction, and export method is agreed for the deployment.
Who the Worker is
Home
Orientation and a map of the other working-memory areas.
Identity
The Worker’s defined identity and engagement boundary.
Role
Owned responsibilities, exclusions, and measures of useful output.
Objective
The recurring job and the mapped workflow behind it.
Agreement
Operating rules, approval ownership, and escalation expectations.
Tools
The approved connection map and the purpose of each connection.
People
Workflow owners, reviewers, contacts, and the subjects they own.
What the Worker is doing
Tasks
Human-readable context for active and queued work.
Activity history
Dated records of configured task events, decisions, and outcomes.
Inbox
Escalations and human replies captured through configured channels.
Knowledge
Durable workflow facts, terminology, process, and approved style guidance.
Capabilities
Documented procedures for approved tools or engagement-specific functions.
Control
Working rules make ownership visible.
A safe operating map tells the Worker what context to use, which connections belong to the workflow, and when a designated person should resolve an exception or approve an action.
Keep working memory current
The operating loop reads relevant context before a task step and records the configured result afterward so the next session can reorient.
Use approved connections
The workflow uses the model, tool, and communication paths mapped for the engagement. A missing permission or connection becomes an exception to resolve.
Pause and escalate uncertainty
When context is missing, a rule is unclear, or an action reaches an approval boundary, the operating map calls for the task to pause and route to the designated owner. That behavior is tested before launch.
Approval boundary
High-impact actions are mapped to a human owner.
Workers typically begin in observe, draft, or review mode. Before launch, the client and Taurist map which business actions a designated person must approve, who owns each exception, and how the task should escalate. Bounded routine completion is considered only where the workflow and review responsibilities support it.
See the approval-level frameworkExternal communication
Publishing or production changes
Spending or budget commitments
Deletion or hard-to-reverse changes
New third-party data sharing
Map one real workflow
Decide the operating boundary before the build.
Start with one recurring job. We'll map its systems, data paths, approval owners, and escalation moments.
Build
Six steps from scope to supervised work.
The build process makes the role, processing paths, working memory, approvals, connections, and proof cases reviewable before the Worker moves into its agreed operating mode.
Scope
Agree the role, recurring workflow, inputs, outputs, data, tools, contacts, exclusions, and workflow owner.
Draft
Write the charter, initial memory structure, approval map, and escalation rules for client review.
Provision
Select and configure the environment, runtime, approved model endpoint, regions, retention expectations, and support access.
Connect
Authorize each required tool and communication path, keeping authentication material separate from worker-authored memory.
Prove it
Run representative cases, verify records and escalation behavior, and test an intentionally out-of-scope request.
Go live
Begin with the agreed supervised mode—typically observe, draft, or review—then adjust scope through the change process.
Learning a new capability
When your Worker needs a tool that does not exist yet.
A new capability follows a defined test-and-promotion loop. It is practiced away from live work, compared with expected results, documented, dry-run, and activated through the agreed change process.
Non-live practice environment
- 01
Define a test case
Set the input, expected result, and acceptance conditions.
- 02
Attempt in practice
Run the procedure in a non-live environment with synthetic or designated test data.
- 03
Score the result
Compare the output with the expected answer and operating rules.
Passed repeatably? - 04
Review and adjust
Investigate failures, update the procedure, and repeat the case.
No: adjust and retry - 05
Document
Record the approved procedure, dependencies, limits, and regression cases.
Yes: document - 06
Promote with control
Install, dry-run, review, and activate through the deployment change process.
New capabilities are developed and evaluated in a non-live practice environment using synthetic or client-designated test data.
A capability is tested against defined expected results more than once, and useful regression cases are kept for later changes.
A capability is documented, added to the approved connection or tool map, dry-run, and promoted through the agreed change process.
Common questions
Questions about data, access, memory, and approval.
The most useful answer is tied to a specific workflow and deployment. These answers describe the operating model and the decisions confirmed before launch.
Need your deployment mapped?
Bring one recurring workflow. We'll identify the boundary, approved paths, owners, and open requirements.
Persistent Worker memory is stored inside the environment selected for the deployment. Task data may also be processed through the approved model endpoint, connected business tools, communication channels, and Taurist support paths required by the workflow. The relevant providers, regions, and data flows are confirmed before launch.
A useful workflow may need an external model endpoint, a client system, a communication provider, or a support path. Those services can process the task data needed for their step. The deployment map identifies each approved path, its purpose, and the available data-handling terms.
Client-designated workflow owners approve the business actions mapped for human review. Taurist handles monitoring, maintenance, and support changes within the agreed engagement scope. Provider responsibilities and any client administrative duties are documented separately before launch.
Each connection is mapped by purpose, permission scope, approval owner, authentication method, and revocation path. A client may revoke access in the source system where the provider supports it, while Taurist can remove or update the Worker connection through the agreed maintenance process.
The client can inspect the human-readable working memory and configured activity history maintained for the Worker, using the access or export method agreed for the deployment. Any formal audit evidence, retention, completeness, or export requirement is agreed separately.
They are addressed during discovery and contracting before deployment. The parties confirm relevant providers, processing regions, retention and deletion expectations, subprocessors, access responsibilities, required data-processing terms, and any assurance evidence the client needs to evaluate.
One defined job
Map how your first Worker should operate.
Persistent Worker memory remains readable inside the environment selected for the deployment. Task data may also be processed through the approved model, tool, communication, and support paths. One Worker handles one defined job, while designated people retain approval wherever the workflow requires it.
Let's map how your Worker operates
Hi, I'm Worker Bee. Tell me one recurring workflow, and I'll help map its environment, connections, working memory, approval owners, and escalation path.