Alchemist Cross-Project Proposals

Your project’s Alchemist agent can propose tickets to another Alchemist project, not just your own. Nothing runs on the target side until that project’s builder reviews and approves the proposal, so the other project stays in control of its roadmap. This guide covers the full flow from filing a proposal to learning whether the work shipped.

The built-in Chipp platform channel

Every Alchemist project comes with one outbound proposal link already wired up: a connection to the Chipp platform team’s own Alchemist project. You do not need to request access or configure anything. If your project hits a platform bug, a missing capability, or a performance problem you cannot fix yourself, your agent can surface it directly to the people who can.

From a conversation with your project agent, you might say:

“We keep hitting out-of-memory errors on every deploy. Please ask the Chipp platform team to look at it.”

Your agent files a structured proposal into the platform team’s Approvals lane. You get a confirmation in chat, and the platform team reviews it on their side. If they accept, real engineering work starts and you hear back when it ships.

How proposals work

A proposal is a ticket description, filed by your agent into another project’s Approvals queue. The target project’s builder sees it alongside any other pending approvals, reads the details, and decides to accept or decline. Accepted proposals become real tickets that run through the target project’s full Alchemist pipeline. The source project (yours) is not involved in the execution and cannot affect it.

Key properties:

• Nothing runs until approved. Filing a proposal does not trigger any work on the target side.
• The target project stays in control. Approvals, rejections, and prioritization are entirely the other builder’s decision.
• You are notified at each milestone (decision time and when the work ships or fails), so you do not need to watch the other project’s dashboard.

Requesting access to other projects

The built-in platform link is automatic, but proposals to any other Alchemist project require an explicit connection. To request one:

1. Open your project’s Access tab and find Cross-project proposal links. Click Request a link and enter the target project’s ID (ask that project’s owner for it). Or ask your project agent to request access with the target project’s ID; the agent calls the request_ticket_proposal_access tool. Both paths send the same request.
2. Optionally include a short message for the target team and up to 5 email addresses to receive decision and outcome notifications.
3. Your request lands in the target project’s Approvals tab. An owner on that project approves or rejects it. Until then it shows as Pending in your own Access tab.

Once approved, your agent gains access to a propose_ticket_to_<target> tool and a check_proposal_status_<target> tool for that link.

Only project owners (and organization owners or admins) can see and manage proposal links. Editors and viewers see a short note instead.

Managing your links

The Cross-project proposal links section on the Access tab shows both directions:

• This project proposes to lists your outbound links, including the built-in platform link, plus any requests still waiting for approval. For each active link you can Edit emails (the decision and outcome recipients) or Revoke it.
• Projects that propose to this one lists inbound links from other projects. You can Revoke any of them.

Revoked links stay in the list, marked revoked, so you can see the history.

What the target builder sees

The link request appears as a “Link request from” card in the target project’s Approvals tab. It shows your project’s name, your organization’s name, and your message (if you included one). The target builder approves or rejects it like any other approval.

Revoking a link

Either side can revoke a link from the Access tab. The source project revokes it under This project proposes to; the target project revokes it under Projects that propose to this one. Once revoked, the source agent loses its propose_ticket_to_<target> tool for that project.

Revoking a link does not affect proposals already filed and in progress. Pending proposals from a revoked link are not automatically rejected; the target builder handles any in-flight proposals manually.

To reconnect after a revoke, send a new request. The link comes back only when an owner on the target project approves it. This also applies to the built-in platform link: if you revoke it, it is not re-created for you automatically.

Filing a proposal from chat

Once a link exists (either the built-in platform link or an approved outbound link), your agent can file proposals mid-conversation. Just describe the problem or request and ask your agent to propose it.

Your agent will:

1. Ask clarifying questions if the description needs more detail.
2. Compose a structured proposal (title, description, acceptance criteria).
3. Call the propose_ticket_to_<target> tool to file it.
4. Return a structured acknowledgment in chat: the proposal ID, the title as filed, and confirmation that it is waiting for review.

Proposal caps: to prevent noise, each outbound link has a cap on pending proposals (proposals not yet decided). By default, each link allows up to 5 pending proposals at a time. The target project also has its own overall caps shared by every source (by default 25 pending proposals and 10 proposals filed in any rolling hour). If your agent tries to file a proposal that would exceed a cap, it will tell you and wait. The caps reset automatically as proposals are decided.

How decisions come back

When the target builder decides on your proposal, you are notified over these channels:

• Email: one message per decision, sent to the addresses on the link’s notify list. If that list is empty, the notification goes to the account email of the person who set up the link. Change the list any time with Edit emails on the Access tab.
• Slack: if your project has a Slack channel configured under Alchemist notifications settings, the same decision summary posts there.

Rejected proposals

A rejection notification names the target project, the proposal title, and the decision. If the target builder included a reason, it appears in the notification and is also visible in the sent-proposals view and via the status tool.

Accepted proposals

An acceptance notification confirms:

• The proposal was accepted and work has started.
• The ticket references that were created (for example, PROJ-42 or multiple refs if the proposal was split into coordinated tickets).
• The count of tickets dispatched.

How outcomes come back

Acceptance starts work, but you need to know how that work ends. The platform sends a second notification when the dispatched ticket reaches a terminal state:

• Shipped: the ticket merged and deployed successfully. The notification includes the ticket reference, a summary of what landed, and confirmation that the fix is live.
• Did not land: the ticket failed or was cancelled on the target side. The notification honestly reports that the work did not ship and that the target team has been notified. It does not fake success.

If a proposal dispatched multiple tickets, the outcome notification waits until all of them finish and summarizes each one, so you get one message covering the whole scope rather than one per ticket.

These lifecycle notifications use exactly the same channels as decision notifications.

Asking your agent for live status

You do not need to wait for a notification. You can ask your project agent for the current status of any proposal at any time:

“What happened to the memory proposal we filed last week?”

Your agent calls check_proposal_status_<target> and returns a structured summary. The status field covers the full lifecycle:

State	Meaning
pending	Filed and waiting for the target builder to decide
rejected	Declined, with the reason if one was given
in_progress	Accepted; the dispatched ticket is still running
shipped	The dispatched ticket landed and deployed
did_not_land	The dispatched ticket failed or was cancelled

The status for accepted proposals reflects live data from the target project’s ticket pipeline, so in_progress updates to shipped or did_not_land as soon as the ticket reaches a terminal state.

If you ask without a specific proposal ID, the tool returns the 10 most recent proposals filed via that link.

The sent-proposals view

Your project’s Alchemist dashboard includes a Sent proposals section that lists every proposal your agent has filed via outbound links. It shows:

• The proposal title and the target project it was sent to.
• The current state (pending, rejected, in progress, shipped, or did not land) as a colored badge.
• Decision details: when the decision was made, the ticket refs created if accepted, and the reject reason if declined.

This section is only visible when your project has at least one outbound link or has sent at least one proposal. If neither is true yet, the section is hidden.

The view is read-only. Link requests are reviewed in the target project’s Approvals tab.

The daisy-chain pattern (agencies and whitelabel builders)

Cross-project proposals are not limited to the Chipp platform link. If you run a platform for your own customers (for example, an agency whose clients each have their own Alchemist project), your customers’ agents can propose tickets to your project using the identical mechanism.

Your project is the target. Your customers’ agents request links to your project. You approve or reject each link request from your project’s Approvals tab. Once a link is active, your customer’s agent can propose improvements, bug reports, or feature requests to your project’s Approvals lane. You decide, and they hear back when the work ships.

This gives agencies and whitelabel builders a structured channel from clients into their own development backlog, without giving clients direct access to write tickets.

FAQ

Do proposals bypass my Approvals lane? No. Every proposal lands in the Approvals queue and requires an explicit decision. Nothing runs until you approve.

What if the notified email address is wrong? The notification emails are captured when the link is requested. The dashboard does not offer a way to edit them yet.

Can I file a proposal programmatically? The propose_ticket_to_<target> and check_proposal_status_<target> tools are available to your project agent in chat. The Alchemist Cloud Tickets MCP server exposes request_ticket_proposal_access for requesting a link. See Alchemist Cloud Tickets MCP for connection instructions.

Is there a webhook or push API? Not in the current version. Email and Slack notifications plus the status tool (from chat) are the supported channels for v1.

Next steps

See Alchemist Tickets for how dispatched tickets execute once a proposal is approved, and Alchemist Work Review for reviewing finished work on your own project.