Skip to content

ASK ME: "approve and deliver": one click sends the exact sentence shown on the card to the named agent, as the owner's input #713

Open

Description

@Swiftchaos

Problem / motivation

Some sign-offs need the owner's own input in a specific agent's session, not a message relayed by the orchestrator. Examples are writing to a live system, uploading something outside the machine, or spending money. Today the orchestrator puts the exact sentence on an ASK ME card. The owner then finds that agent, opens its composer and pastes the sentence in. With several agents running this is slow, and copying invites slips in the wording.

What I see in the v0.5.5 release:

  • The ASK ME answer goes to the orchestrator as a HUMAN ANSWER inform (AskMeTab.tsx, to: 'god'). The app does not deliver it directly to the agent the card is about.
  • In the release build, queued terminal input is logged with the same source whether the owner typed it or it is an automatic nudge. So the submit log does not show which input came from the owner. (This part of the code does not appear to be on public main yet, so I have not cited files for it.)

Proposed solution

A narrow, opt-in exception to orchestrator-mediated dispatch (#44, #45). The orchestrator prepares the request and is told the outcome. Only an explicit owner click lets the app deliver the shown sentence directly to the named session.

  • The orchestrator adds an action to an ASK ME entry: one target agent, one short sentence and an expiry. There is one action per card. The sentence must be a single line of printable text under a length cap, with control, zero-width and bidirectional characters rejected. The idea is that the sentence says what it approves, rather than just "yes".
  • The card shows the target agent and session, the exact sentence, whether Enter will be pressed, and the expiry. Next to them is an Approve and deliver button.
  • On the click, the main process freezes that exact payload and checks it against what the card displayed. Each approval can be used once, atomically, and that survives an app restart. Later edits to the card cannot change an approved payload.
  • Just before typing, the app re-checks the expiry and that the target is still the same session. Delivery uses the normal queue gates and a distinct source, owner-approval.
  • Approved, submitted and acknowledged are recorded separately. An unclear outcome stays visible as uncertain and is never retried without the owner.
  • The orchestrator is informed of what was delivered.

Default policy proposed: the click counts as the owner's word, because the card shows the full sentence and the target, there is one action per card, and it expires. Optional setting: the owner types or edits the sentence on the card, and exactly that is delivered.

Limit: this records approvals made through the app's UI. It does not give tamper-resistant attribution or isolation between agents that run under the same OS account.

Delivery should reuse the common queue path. Acknowledgement support (for example, the prompt-hook confirmation proposed in #463) would need checking for each provider.

I'm willing to contribute a PR if this fits the project. Please confirm the design, and which branch it should target: the delivery code in the v0.5.5 release looks newer than public main.

Screenshot, mockup or recording

Mock-up of the proposed ASK ME card with an Approve and deliver button

Mock-up of the proposed card. Not a screenshot; all content is made up.

Alternatives considered

  • Keep pasting into the agent's composer. It works, but it is slow with several agents, and the submit log cannot tell it apart from automatic input.
  • Route the answer through the orchestrator. That relay is what these sign-offs are meant to avoid.

Related: #43, #44, #45, #454, #463, #192.

Area

The hive (memory, routing, GOD agent)

Pre-flight

  • I attached a screenshot, mockup or recording above.
  • I searched existing issues and discussions, and this isn't a duplicate.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions