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.