An agent needs a workspace, not just a persona

A persona shapes the voice. A workspace shapes behaviour — and makes visible what an agent knows, may do, changes and hands over.

A carefully written persona can make collaboration more natural. It can hold a critical point of view, ask questions from a professional perspective or maintain a recognisable tone. Once a system reads files, advances plans, invokes tools or prepares decisions, however, character description is no longer enough.

Agents rarely fail because their biography is too short. They fail because the objective and finish state remain vague, sources conflict, the latest status exists only in chat, permissions are too broad or nobody knows which change has already run. The remedy is not a hundred-page personality profile. It is an explicit workspace.

Persona, role and agent are separate layers

A persona defines perspective, tone and interaction style. A role defines responsibility: advise, review, extract, approve or execute. An agent connects a model to state, tools and an action loop. It observes, plans, acts, verifies and updates the work state.

These layers may be combined but should not be confused. „Act as an experienced strategist“ creates neither reliable market data nor approval authority. „Be proactive“ does not define permitted tools. „Stay critical“ is not an acceptance test. A persona may stabilise communication; operational reliability comes from testable rules and technical constraints.

This distinction also limits misplaced trust. Consistent language can feel like consistent knowledge, yet a system may express correct, stale and invented claims in the same confident voice. Trust must therefore attach to evidence, provenance, tests and controlled action — not personality.

The workspace externalises project state

A dependable workspace answers the same questions at every session start: What is the objective? What has been completed? Which sources govern? Which artifacts are current? What is open or blocked? Which changes are permitted? What requires human decision?

This information should not live only inside a transient conversation. It is maintained as structured state outside the model. A compact workspace might contain:

project/
  brief.md             # objective, scope, non-goals
  status.md            # current state, open items, blockers
  sources/             # approved inputs with provenance
  decisions.md         # decisions and rationale
  artifacts/           # produced outputs
  checks/              # tests and acceptance criteria
  handoff.md           # transfer to the next session

Names can change; functions cannot. The agent needs a source of truth, clear separation of input and output and a reproducible start. Chat history may supply additional context, but it is a poor project index. Long conversations contain obsolete proposals, rejected options and implicit assumptions. A status artifact retains only the valid state and points to evidence.

An objective needs a testable finish state

„Produce a good analysis“ expresses intent but not completion. An agent needs an objective contract: expected artifacts, quality characteristics, boundaries and a definition of done. For analysis, this might require three named source classes, visible uncertainty, traceable calculations, separated facts and recommendations and a list of unresolved decisions.

The contract prevents activity from masquerading as progress. A task can be marked complete only when agreed evidence exists. If a source is missing, the agent records a blocker instead of filling the gap rhetorically. If a test contradicts the result, status does not become green through optimistic prose; the deviation remains visible.

A useful state model distinguishes at least planned, in progress, in review, blocked, accepted and rejected. Every transition needs a trigger. That turns a sequence of plausible replies into an observable process.

Source hierarchy beats context volume

More files do not automatically create better context. A workspace needs precedence: binding specification over informal notes, approved version over draft, primary source over summary and current state over archive. Conflict is resolved by explicit priority, not the paragraph loaded most recently.

Important sources should carry origin, date, scope and status. W3C PROV supplies a formal vocabulary for entities, activities and responsibility. Everyday projects may use a lighter provenance card: Where did the document come from? Who approved it? Which transformation was applied? Which output derives from it?

The agent also records which sources were actually used. „Present in the folder“ is different from „consulted for this decision“. This supports later review and prevents a result being legitimised by a large but irrelevant knowledge collection.

Tools need capabilities and boundaries

A workspace contains not only information but also a permission matrix. Each tool receives a purpose, allowed objects, maximum scope, preview requirement and confirmation threshold. A research agent may read and create notes but not overwrite originals. A document agent may write to an output folder but not publish. A transaction is simulated before explicit approval.

This follows least privilege. OWASP highlights risks in agentic systems such as tool misuse, goal manipulation and uncontrolled action chains. Written prohibitions are necessary but insufficient. The host must enforce access, validate input, inspect output, apply timeouts and make sensitive operations visible.

Bound the action envelope as well: maximum steps, cost budget, runtime, retries and stopping conditions. Without limits, an agent can repeat errors, consume resources or multiply side effects.

Plan, act and observe — without circling blindly

The ReAct paper demonstrates the value of interleaving reasoning, action and observation. Real projects need explicit gates around that loop. Before an action: Are prerequisites satisfied? Is the tool permitted? Is the operation reversible? After an action, inspect actual state rather than merely accepting a model's description.

A robust cycle is: read state → choose next step → check authority → execute → observe result → test acceptance criterion → update status. A failed gate routes to correction, escalation or safe stop — not automatically to the next action.

Deterministic checks belong in code or rules: file existence, schema, hashes, totals, link status and tests. The model interprets ambiguous situations; it should not guess mechanical truth from prose.

Checkpoints should reflect risk

Human-in-the-loop does not mean clicking „OK“ after every small step. Too many trivial approvals create fatigue; too few hide consequential decisions inside the system. Place checkpoints where harm, irreversibility, uncertainty or external impact increases.

Typical approval points include publication, external communication, money movement, sensitive-data access, deletion, permission changes and decisions about people. The agent prepares a decision packet: planned action, affected objects, evidence, uncertainty, alternatives, expected side effects and rollback path.

Approval applies only to the displayed scope. A changed objective, dataset or action requires renewed review. Otherwise a small confirmation silently turns into general authority.

Independent review requires genuine distance

A second model response may reveal errors, but it is not automatically independent. If creator and reviewer share the same sources, assumptions and blind spots, the result may be only linguistic variation. Review improves when perspective and evidence are separated.

The reviewer receives explicit criteria, can inspect primary sources independently and sees claims together with evidence. Critical results also use deterministic tests, sampling or accountable domain review. Model diversity may help, but it is not a substitute for a sound evaluation method.

The workspace therefore stores more than „reviewed“: reviewer, scope, method, findings and residual risk. A review without a visible standard is an opinion; a review connected to tests and evidence becomes a control.

Handoff is a first-class artifact

Agentic work crosses sessions, models and people. Without a handoff, every instance reconstructs the project. Rationale disappears, rejected approaches are repeated and stale assumptions return.

A good handoff contains objective and scope, current state, produced artifacts, consulted sources, decisions, open risks, recommended next action and pending approvals. It distinguishes facts, assumptions and proposals. It also says what should explicitly not be repeated.

The next session begins with a consistency check: Do referenced files exist? Do versions and hashes match? Are blockers still current? Only then does execution continue. Memory becomes verifiable state rather than narrated recollection.

Parallel work needs ownership rules

Multiple agents or sessions may accelerate work but can also create conflict. When two instances edit the same file, the last save is not a quality decision. The workspace therefore defines task ownership, isolated branches and integration rules.

Independent subtasks with clear outputs can run in parallel. Shared core artifacts need an owner or merge process. Integration includes semantic review: two individually correct sections can still contradict each other. Central status changes only after successful integration.

Parallelism is therefore not only a performance option. It is a problem of state consistency, provenance and accountability.

The Agent Workspace Canvas

Design a one-page workspace for a real use case:

1. Objective contract: outcome, non-goals, definition of done and risk.

2. State: status fields, valid artifacts, blockers and next action.

3. Sources: hierarchy, provenance, freshness, access and conflict rule.

4. Tools: permitted functions, scope, budgets, preview and confirmation.

5. Loop: observation, planning, action, verification and state transition.

6. Checkpoints: Which decisions need people, and what evidence will they see?

7. Record: Which actions, sources, versions and reviewers are logged?

8. Handoff: What must the next instance inherit reproducibly?

9. Stop: Which failures, uncertainties or limits halt the system?

Test the design with an ordinary path, a conflicting source and a failed tool action. If the agent can explain its state, stop safely and create a dependable handoff in each case, a persona is beginning to become an operating system.

All materials to download — the topic overview and the worksheet:

Scope: Products use "persona" and "agent" inconsistently. This article uses persona for a defined perspective and agent for a system that can change state or invoke tools within bounded authority. A workspace is not a particular product; it is the controlled environment of objectives, state, sources, artifacts, permissions, logs and checkpoints. The cited frameworks do not guarantee safety; controls must be implemented and tested in proportion to risk.