Start an AI agent on a My Architect project

Start by connecting your agent to My Architect and confirming which project it may use. Then find a specific feature or work item and read its requirements. Your first successful outcome is a verified task brief: the project, intended result, relevant sources, current ownership and next action.

For AI agents

Use the documentation index to select a task guide, or read this quickstart as raw Markdown. For an existing session, follow resume and handoff. For parallel work, follow coordinate multiple agents.

Public documentation describes supported procedures. Confirm the exact project, read its current requirements, and preserve the user’s authorized scope before writing.

Before you begin

You need access to the intended My Architect project and an agent host that supports the MCP connection. Open API Keys in the application and use its Connect configuration for your account; the connection guide includes examples. Keep credentials in the host’s supported secret or environment configuration, outside shared documentation and committed examples.

The published MCP package is @my-architect/mcp. Its local stdio process connects to the configured backend. The hosted connection uses MA_API_URL=https://my-architect.app and MCP_API_KEY; an unset server URL selects the local development default, not the hosted project.

Install the My Architect workflow plugin when your host supports it. The MCP connection provides tools; the plugin provides task and coordination procedures. A raw MCP connection does not by itself install those procedures. After updating, restart the running MCP process and relevant agent session; an installed update does not replace an already running process.

Use the account’s connection instructions and the host’s current plugin instructions for installation syntax. This guide starts after the tools are visible.

1. Confirm the exact project

Read the repository’s AGENTS.md, CLAUDE.md and existing project binding, when present. Preserve the exact project ID, including spaces and punctuation. If no binding exists, use list_projects and resolve which project the user intends before writing. The newest project or a single result is not sufficient evidence of the binding.

For an unfamiliar existing project, first inspect the product catalog or supported read-only migration inventory. Do not run initialization or repair merely to discover what is there. An unavailable reader is not an empty project.

2. Discover the relevant capability

Call search_product_features globally before narrowing to an area. This example shows tool arguments; replace the placeholder with the confirmed project ID and search for your actual task.

{
  "pid": "<confirmed project ID>",
  "query": "account onboarding",
  "limit": 10
}

Read candidate descriptions and linked work. Choose the stable feature or work ID that matches the request. If there is no relevant existing capability, record that finding and model the new request without duplicating nearby work.

3. Build the task brief

Use get_scoped_context for the selected target. Read every applicable requirement manifest page and the full details needed for the task. Keep the same snapshot across continuations and preserve explicit gaps.

The brief should answer:

• What outcome has the user requested?
• What current behavior and proposed change apply?
• Which requirements and decisions constrain this work?
• Which work item will own the result?
• Is anyone already responsible for that work?
• What is the next action, and what would demonstrate success?

Follow Read the right project context for snapshots, detail windows and incomplete sources.

4. Make accepted implementation visible

When the user has asked for implementation, reuse or create a proportionate work record, connect it to the relevant product capability and read get_epic_flow plus get_epic_flow_capabilities. Enqueue the relevant epic if needed and obtain your own appropriate claim before execution.

A coordinator claims an epic. An independent worker claims an eligible child work item. A coordinator implementing a separate child also needs that child’s claim. Follow Coordinate multiple agents for the exact sequence.

Read-only research can remain read-only. A request to inspect a project is not permission to activate its backlog. Existing publication, data-access and delivery restrictions still apply.

Verify the first result

Read back the chosen work item and its relevant flow entry. Confirm that IDs, scope, claim holder and next step match your brief. Save a durable source document when the task needs one. Continue implementation only for the scope you have actually accepted and claimed.

If the connection fails, preserve the last verified state and report the specific failure. A server failure does not mean the server project is empty and is not a reason to create a replacement local project.

Connect to the intended My Architect project and prepare a task brief for
the onboarding change. Use existing features and work where they fit.
Show the applicable requirements, source gaps, ownership and next step.
Do not create sample content or treat a failed read as an empty project.

Next: Manage project work or coordinate several agents.

Verified against app/MCP 1.11.0 and workflow plugin 2.6.0 on October 13, 2026. Confirm the connected server’s capabilities before applying a procedure.