Agent access
Let agents work on the plan through explicit, reviewable operations.
AfterPencil exposes the same semantic model used by the interface through a browser API and an OAuth-protected MCP server.
await window.afterpencil.summary()await window.afterpencil.planImage()01
A plan is more useful than a screenshot
A browser agent can often click an interface, but pixels do not explain which line is a wall, which opening belongs to it or which operation keeps the model valid. AfterPencil exposes named commands and structured summaries so an agent can reason about the project it is changing.
The interface and agent paths converge on the same model operations. This avoids a hidden automation format and means checks, history and derived outputs can respond normally.
02
Work with the project already open in the browser
The `window.afterpencil` API gives a supervised browser agent access to project summaries, plan data, quantities, catalog entries, images and editing commands. It can choose a level or view, add common elements, apply operations and wait until the interface has rendered the result.
This path is useful when the person and agent are working together in the same session. The visible editor remains the review surface, and the public `llms.txt` plus short guides describe the available methods.
03
Connect external tools through MCP
The remote MCP server supports agents that do not have a browser. OAuth asks the person to choose a workspace and approve permissions. The resulting token reaches only the projects and actions allowed by both that consent and the person’s workspace role.
MCP can list and create projects, read summaries and quantities, apply commands and save through the API with version checks. It does not receive an unrestricted database connection or another user’s files.
04
Read, act and verify
A useful automation flow begins by reading the relevant state, applies a small explicit change, then checks the resulting model and visual output. Commands return what they created or a structured error. Images of the technical plan and 3D views let an agent verify more than a successful HTTP response.
That loop matters for trust. An agent should not claim a room was enlarged merely because a command ran; it should inspect dimensions, checks and resulting views, then present the change for human judgment.
05
Access remains a product decision
Browser access exists within the session the person opened. MCP uses OAuth, workspace selection and scoped permissions. API keys belong to a workspace and webhooks are signed. Leaving a plan or disconnecting an integration should not silently grant broader access.
Plus and Pro include agent integrations because they serve repeatable professional workflows. Plan quotas and permissions are separate: paying for access never overrides a reader role or project boundary.
06
Automation does not become professional authority
Agents can accelerate explicit work, explore alternatives and summarize outputs. They do not certify building-code compliance, structural safety, constructability or a final price. Those conclusions need the responsible people, sources and review appropriate to the project.
The command vocabulary is intentionally narrower than arbitrary code execution. When a capability is unavailable, the agent should say so or use the documented API instead of manipulating internal state.
07
Choose the access path that matches the task
Use the page API when the person wants to watch and review work in the open editor. Use MCP when an external agent needs permissioned access without a browser. Use REST, OpenAPI, keys and webhooks when an integration has a stable system-to-system workflow.
Start with the machine-readable site summary, continue to the editor guides for browser work, or connect to the MCP endpoint with OAuth. The marketing pages describe the boundary; the canonical technical references describe exact schemas and methods.
08
Build integrations on stable names
Commands, events and fields use stable English identifiers even when the human interface is Spanish. This gives agents and integrations one technical vocabulary while visible explanations remain localized. Changes are documented with the implementation.
AfterPencil is designed to be consumable by assistants and operable by permissioned agents. Those are separate promises: clear static HTML and `llms.txt` support understanding, while explicit APIs support action.
09
A concrete assisted change
Suppose a person asks an agent to widen the patio opening and report what changed. The agent first reads the selected level and opening, checks the available wall length, and applies the documented resize or replacement command. It then reads the new dimensions, requests plan and 3D images, and checks whether project review reports a conflict. The response can link the visible result instead of presenting an unverified success message.
The same discipline applies to larger automations. Break the request into model operations, preserve one understandable history step where appropriate, and return structured errors when a constraint cannot be met. Human review is not a ceremonial last click: it is the point where design intent, local knowledge and professional responsibility meet the changed project. The APIs make that review more informed; they do not make it optional.
AfterPencil
Technical references
Editor reference for agents
The machine-readable entry point and recommended verification loop.
JavaScript page API
Methods exposed through window.afterpencil in the open editor.
MCP tools
How external agents connect and use the supported commands.
OpenAPI
The REST contract for authorized integrations.
MCP endpoint
The remote OAuth-protected MCP endpoint.