# Evaluate the environment an agent will actually use. Reviewed: 2026-10-18 Canonical: https://clankercloud.ai/learn/evaluate-agent-workspace Evaluate an agent workspace by testing the actual client, connection, tools, saved state, recovery, and handoff your workflow requires. In Clanker, use a small Project with known evidence, make one saved change, inspect it, and resume in a fresh task. Record observed behavior and usage rather than inferring reliability from a first answer. ## What you are working toward An evidence record showing whether the selected agent and environment can complete your workflow. ## Start with - A fictional or approved task with a known result - The exact client, account, and interface you intend to use - A reviewer and a short log of observed behavior ## Define the environment under test Name the agent, client version, account, Project, connection route, and required operations. “Works with agents” is too broad to evaluate. A native Workspace Agent producing a report and an external MCP assistant editing a file are different trials. If you need a BYOA harness, include its host, inference provider, and runtime settings. Write one acceptance sentence: “The receiving agent can read the selected packet, save a supported conclusion with references, accept a correction, and hand the current version to a fresh task.” Add runtime restoration or computer access only if the production workflow needs it. This keeps the trial bounded and its result interpretable. ## Test access and capability before generation Use fictional sources with one known missing field and one source conflict. Ask the actual client to locate the Project and read the file contents. Check the exposed tool list and permissions. A connector in a menu, a successful sign-in, or a list of filenames does not establish that the needed operation works. Review the scope of the connection: Workspace MCP grants act across the connected user’s accessible Workspace rather than only the Project named in the prompt. Test the permissions required for the intended task without adding billing or execution access by default. Record a missing capability as a limitation instead of quietly switching interfaces. ## Use a small set of observable cases These are proposed checks for your own trial, not published product results. Run the cases relevant to your workflow and retain the inspected artifacts. | Case | Action | Evidence to inspect | | --- | --- | --- | | Read | Find and read the known source packet. | Actual content and correct Project selection. | | Save | Write the requested bounded output. | File exists, opens, and cites the right evidence. | | Correction | Change one source fact and revise. | Current saved file reflects it consistently. | | Conflict | Present a contradictory proposal. | Approved and proposed facts remain distinct. | | Handoff | Resume in a fresh authorized task. | Current sources, output, and open questions are recoverable. | | Runtime, if needed | Finish a run and inspect later saved state. | Confirmed save and retained known file. | ## Test revision behavior without risking real work Keep the first output, introduce one controlled correction, and ask for a revised file plus a short change note. Inspect the whole deliverable for stale facts. Where the interface uses expected revisions, verify that the agent rereads after a conflict rather than overwriting another task’s change from an older copy. For commands or external actions, discuss recovery before the first trial. Retain the original identifiers and inspect existing results after a timeout. Do not deliberately repeat a real purchase, message, or record update to test idempotency. A fictional draft or harmless computation can establish the working recovery procedure without creating unwanted side effects. ## Check the record a person can review For external MCP changes, confirm the agent follows the current managed Session workflow and records concise public progress and a final result. The user should be able to find the task and its saved artifacts in Workspace. The external private conversation is not automatically imported, so inspect what was actually recorded. If a takeover test is required, use a harmless bounded task and verify the documented control and resulting state. Treat cancellation of queued or submitted work separately from preventing later calls. A stopped task cannot recall effects already submitted to another service. Record the specific outcome instead of calling all cancellation “rollback.” ## Keep observations separate from assumptions Mark each requirement as observed, needs revision, unavailable, or not tested. Record setup effort, manual repairs, actual usage, and the account features used. A runtime that restores one saved file has demonstrated that case; it has not proven every private process or tool is recoverable. Use Clanker when the tested combination of Project context, selected agents, task visibility, and retained outputs meets your requirements. Recheck capability assumptions after meaningful client or server changes. This page provides a method for choosing an environment, not an accuracy, speed, cost, or reliability benchmark against other products. ## Try this prompt Copy into a Workspace Session. Opening Workspace does not send it automatically. ```text Evaluate the exact Clanker agent environment I intend to use with a bounded fictional task. Record client and account configuration, interface, exposed tools, and granted permissions. Test reading known sources, saving a referenced output, one correction, a known conflict, and a fresh-task handoff. Test runtime restoration only if needed and inspect confirmed saves. Keep original operation identifiers after uncertain results. Log observed, needs revision, unavailable, or not tested for each requirement, plus actual usage and manual repairs. ``` ## Before using the result - The trial uses the intended client and interface throughout. - Each pass has an inspected file, source, or task record. - Untested requirements remain labeled as untested. - The decision includes limitations and observed usage. ## Common questions ### Is a good agent answer enough to evaluate its workspace? Also test the saved file, a correction, a source conflict, and a fresh-task handoff. If your workflow needs cloud runtime or external actions, test their specific persistence and recovery requirements separately. ### Is this an agent benchmark? No. It is a bounded evaluation method with authored acceptance cases. Run it with your actual account, client, and tools, retain the artifacts, and record the observed outcome. It reports no measured comparative advantage. ### Can I use a native Agent result to prove external MCP support? No. Test the interface you intend to use. Native Agents, hosted MCP, BYOA, HTTP, and Sandbox API have different tool coverage, authorization, and runtime behavior. ## Sources - [Clanker: Workspace product behavior and feature availability](https://clankercloud.ai/faq) - [Clanker: external-agent access, permissions, and managed Sessions](https://clankercloud.ai/workspace-agents) - [Clanker: current agent instructions and HTTP access](https://workspace.clankercloud.ai/for-agents.md) - [Clanker: BYOA setup, runtime, saved state, and usage](https://workspace.clankercloud.ai/#page=faq&tab=articles&article=bring-your-own-agent) - [Clanker: standalone Sandbox API contract](https://clankercloud.ai/api-docs) ## Related - [A small packet the next agent can verify.](https://clankercloud.ai/templates/agent-handoff-pack) - [Give the Agent a test with an answer you can check.](https://clankercloud.ai/templates/agent-acceptance-test) - [Choose an environment by what the agent must reach.](https://clankercloud.ai/learn/choose-ai-agent-environment) - [Build an Agent you can test, reuse, and hand over.](https://clankercloud.ai/learn/ai-agent-factory) - [Let the next agent continue from checked work.](https://clankercloud.ai/learn/project-handoffs-between-ai-agents) [Open Workspace](https://workspace.clankercloud.ai) [Current pricing and usage](https://clankercloud.ai/pricing)