Answering Agent Questions

Sometimes a ticket’s agent genuinely needs something from you before it can keep going: a decision, a missing piece of context, or a secret it has no business seeing. When that happens the ticket pauses in an awaiting input state instead of guessing. This guide covers what those pauses look like and how to resolve them.

What an agent pauses to ask about

• Ambiguity or a design choice. The ticket’s description left more than one reasonable way to build something, and the agent would rather confirm the direction than guess and redo the work.
• Missing context it can’t derive from your codebase. Something only you know, for example which of two similar services a change should target.
• A missing credential. The work needs an API key, certificate, or other secret that isn’t in your project’s environment yet. The agent never asks you to paste the value into chat; it mints a secure submission link instead (see below).
• A data repair that needs sign-off. If an agent investigating a data issue proposes a concrete fix, a specific SQL statement against your project’s database, it pauses and shows you exactly what it wants to run, rather than applying it unilaterally.

Where these surface

• A banner on the ticket detail page. The paused ticket shows a card describing the question, with a reply form (or, for a proposed data repair, Approve/Decline buttons showing the exact proposed change instead of a free-text box).
• The Approvals panel on your project dashboard lists every ticket waiting on your reply alongside proposals from your connected channels, so you can see everything needing your attention in one place without opening each ticket.
• Your connected channels. If the ticket originated from Slack or email, the question can also reach you there, depending on how your project is wired up.

How to reply

Type your answer into the reply box on the ticket detail page (or approve/decline a proposed data repair) and submit. Replying doesn’t just unpause the same ticket: it dispatches a new follow-up ticket that resumes the work from where it paused, carrying your answer as additional context. That follow-up shows up linked from the original ticket once it’s dispatched, so the thread stays traceable end to end.

If you don’t have a good answer yet, you can leave the ticket paused; nothing else happens on it until you reply or cancel it (see “Cancel semantics” in Alchemist Tickets).

Over MCP, the equivalent is the reply_to_ticket tool, covered in the Alchemist Cloud Tickets MCP guide.

The secure credential submission link

When an agent needs a credential, it never asks for the raw value in chat, in a ticket reply, or over MCP. Instead it mints a scoped, expiring link and includes it in its question. Opening that link takes you to a small form, no account required, where you submit the value(s) directly:

• Values you submit are encrypted at rest and write-only: nobody, including Chipp staff, can read a submitted secret back out of the system afterward.
• On a managed project, submitted values are applied to your project’s deployment environment automatically at the next deploy.
• On a BYO-repo (dispatch-only) project, the link instead shows you the exact steps to add the value to your own secret pipeline, since the platform doesn’t manage that project’s deployment environment.
• The link expires, so it isn’t a standing door into your project’s secrets.

Next steps

Once a paused ticket resumes, its follow-up runs like any other ticket, see Alchemist Tickets for the full lifecycle, or Alchemist Reports and Audit for how to read what happened next.