Canvas Pilot: the workflow layer above Canvas MCP
Canvas Pilot is built on a simple product belief: the valuable part of student workflow automation is not only seeing Canvas. It is learning what repeats in each course and turning that pattern into a local, review-first workflow.
Access is not memory
Canvas MCP servers are useful because they give an agent access to Canvas. The agent can list assignments, read modules, fetch files, and inspect course pages. That solves the access problem.
It does not solve the repeated-workflow problem. A course often has a durable shape that does not live in one assignment description. One course may publish the real spec on an external site. Another may always require the same reading annotation format. A third may use the same problem-source and PDF delivery pattern every week.
If an agent has to rediscover that structure every time, the user is still paying the coordination cost. Canvas Pilot treats that repeated structure as the product surface.
The workflow shape
Canvas Pilot uses a fixed boundary:
scan Canvas -> approval plan -> student approval -> approved workflow -> review-ready output -> REPORT.md
The scan step does not begin assignment work. It writes a plan and stops. Execution happens only after the student approves selected items. Approved items then route into course-specific workflows that know how to find the real spec, gather inputs, produce a draft, run checks, and report what happened.
Why this is for AI power users first
The public preview is not a no-code consumer product. It is for people who already know how to use local AI agent tools such as Codex or Claude Code and want to stop repeating meaningless Canvas coordination work by hand.
If you are comfortable running an agent locally, reviewing a generated plan, and checking draft outputs before submission, Canvas Pilot can make recurring coursework feel like a one-command workflow. If you are not comfortable with that operating model, the product will feel hard. That boundary is intentional.
Why local-first matters
Coursework data is sensitive. Credentials, school-specific course identifiers, drafts, cookies, assignment inputs, and private overlays should not become part of a hosted multi-tenant service by default.
Canvas Pilot keeps those files on the user's machine. The public repo ships the generic framework. The user's real courses live in local, gitignored configuration and run directories.
What Canvas Pilot is not
Canvas Pilot is not a silent homework service. The default mode is draft production and student review, not automatic submission. The framework is designed around approval, reporting, and local operator responsibility.
Its strongest long-term use case is repeated, structured coursework where the pattern is stable enough to become a workflow. That is the product category: not "one prompt that writes", but "course patterns that persist."
What the public preview proves
The current public preview proves the shape of the system: scan, approval, execute, per-assignment result files, reusable course skeletons, and local-first privacy boundaries. It is early, but the direction is clear.
Canvas Pilot is the workflow layer above Canvas access. Canvas MCP can be part of the input layer. The product value is in what happens after Canvas is visible to the agent.