# A workspace for people who direct AI agents

> A practical founder workflow for directing a coding agent: define one outcome, run the product, inspect evidence, and hand off risky decisions.

Canonical HTML: https://canopyide.dev/blog/a-workspace-for-people-who-direct-ai-agents
Article date: 2026-09-27

A founder can direct a coding agent without writing every line of code. They still need to know what the customer should see, whether the app runs, what changed, and which decisions need a developer. Canopy puts those pieces around the agent's own CLI so the work remains inspectable.

## Start with a customer-visible decision

Suppose a customer cannot retry a failed profile save. The founder's job is to define the behavior: show a useful error, keep the entered value, allow another attempt, and confirm that a successful save persists after reload. That is a better first request than 'make the profile page production-ready.' Give the agent the screenshot, reproduction steps, and acceptance checks. Ask it to inspect the relevant code before changing files. You can judge the customer outcome even if an engineer later needs to review the implementation.

## Know what you must bring to the workspace

Canopy is a local desktop workspace, not a hosted prompt-to-app service. Open an existing repository or the site's small practice project. Install and sign into a supported coding CLI with its own model account, and install the runtime your project uses. Git is needed for branches, worktrees, diffs, and PRs. In Canopy, label the project components and save the real commands for the website, API, or worker. Ask a developer for help with setup or production credentials you do not understand rather than pasting secrets into an agent prompt.

## Make the agent's result visible

Run the project from its saved command and open the actual local URL in Preview. Try the original failure and success paths yourself. If the page still fails, capture the state, viewport, and relevant console or network evidence and give the agent a focused correction. Then inspect the changed files and diff: do they relate to the requested behavior, and did the agent change configuration or data paths you did not ask it to touch? Canopy's current-main README documents agent terminals, local services, Preview, and Agent Workspace in one project; its README can be ahead of the latest installer, so check the exact release and platform you use.

## Separate product acceptance from technical approval

A founder can say whether the flow feels right and whether it solves the customer's problem. That is not the same as approving authentication, payments, privacy controls, migrations, infrastructure, or a production deployment. For those paths, bring a qualified reviewer the repository, branch or PR, run steps, acceptance checks, observed result, tests, and known unknowns. Ask them to inspect the final diff and make the technical release decision. This handoff is more useful than forwarding an agent's confident summary or a video that hides the changed code.

## Resume with evidence, not memory

When you return tomorrow, search the project for the issue, branch, or decision, then check the current working tree and PR. Restart the services that are actually stopped; saved commands do not imply a worker ran overnight. Resume the original CLI conversation if supported and still relevant, or start a fresh bounded task with the goal, decisions, tests, and next action. A second model can review a change, but it does not inherit the first model's private conversation or paid account. Measure progress by an accepted behavior and an inspectable change, not by the number of agent sessions opened.

## Copyable resources

### Founder acceptance card

Use for one small feature or bug; hand the completed card to a technical reviewer when the release is consequential.

````text
Customer problem: [one observed failure or need]
Current behavior and reproduction: [steps]
Expected behavior: [success path and error path]
Project/branch and run command: [ ]
Agent task: inspect relevant files, propose a small change, report the exact tests run.
My check: run the app, repeat both paths, capture result, inspect changed files.
Technical review needed for: [auth/data/payment/security/deployment/other]
Handoff: PR/latest commit [ ]; test results [ ]; unknowns [ ]; reviewer and decision [ ].
````

## Frequently asked questions

### Is Canopy a browser-based app builder?

No. It is a desktop workspace around local projects and installed coding-agent CLIs.

### What can a non-coder review in Canopy?

They can inspect agent progress, the running preview, screenshots, changed files, and PR status. Technical and production decisions still need someone qualified to verify them.

## Sources and further reading

- [Canopy app README: workflow and prerequisites](https://github.com/FluidWorksApp/canopy-ide/blob/main/README.md)
- [GitHub pull request review workflow](https://docs.github.com/en/pull-requests/how-tos/review-pull-requests)

## Related Canopy pages

- [Can a noncoder build software with AI coding agents?](https://canopyide.dev/guides/can-noncoders-build-software-with-ai-agents.md)
- [How to set up Canopy and run your first AI coding agent](https://canopyide.dev/guides/getting-started-with-ai-coding-agents.md)
- [How do I ask a coding agent for a demo I can inspect?](https://canopyide.dev/guides/ask-coding-agent-for-inspectable-demo.md)
- [How to hand an AI-built app to a developer for review](https://canopyide.dev/guides/handoff-ai-built-app-to-developer.md)
- [AI-built app works locally but fails on Vercel Preview](https://canopyide.dev/guides/ai-built-app-works-locally-fails-vercel-preview.md)

Canopy runs installed coding CLIs; CLI accounts, model selection, and provider billing remain separate. Check the installed release before relying on version-specific behavior.