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. Go to your project’s Connections settings page on build.chipp.ai.
2. Find the Outbound proposal links section and click Request a new link.
3. Enter the target project’s identifier. You can optionally set email addresses to receive decision and outcome notifications.
4. Your request is sent to the target project’s builder. They see it in their own Connections settings and can approve or decline.

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

What the target builder sees

The target builder sees your project’s name, the link request reason (if you included one), and a toggle to approve or block. They can revoke an approved link at any time from their Connections page.

Revoking a link

Either side can revoke:

• Source side (you): go to your project’s Connections page, find the link under Outbound proposal links, and click Revoke.
• Target side: the target builder goes to their Connections page, finds the link under Inbound proposal links, and blocks or removes it.

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.

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_<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 and 10 proposals filed in any rolling hour. If your agent tries to file a proposal that would exceed either 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 the channels you configured at link creation:

• Email: one message per decision, sent to the addresses on the link’s notify_emails list. If that list is empty, the notification goes to your project’s builder account email.
• 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. Revoking links and reviewing active requests lives on the Connections settings page.

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 request outbound links to your project from their own Connections pages. You approve or decline each link from your Connections settings. 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? Update the notify_emails list on the link from your Connections settings page. The change takes effect for future decisions and does not retroactively resend past notifications.

Can I file a proposal programmatically? The proposal tools are also available over MCP to any authenticated MCP client. The same propose_ticket_<target> and check_proposal_status_<target> tools are registered on the Alchemist Cloud Tickets MCP server. 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 or MCP) 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.