Questions and Outreach

An agent working on its own hits two situations that need a person: a decision only you can make, and a message you asked it to send. Both go through Wallfacer rather than around it, so every question, message, and refusal lands on the task's record.

An Agent That Needs a Decision Stops and Asks

When an agent reaches something only a person can settle, which database to use, whether something is in scope, which of two designs you meant, it asks instead of guessing. The step parks: nothing after the question runs until an answer arrives.

The task shows a blue Waiting on an answer callout carrying the question as the agent wrote it, where it went, how long it has been waiting, and, once somebody replies, the answer and who gave it. A question that parked on the task itself also carries a field to answer it right there. There are no Approve or Reject buttons on it. An answer is information rather than a decision, and the person reading the task is often not the person who was asked.

A playbook Wait step is the other kind of pause and looks different: Waiting on a signal, naming the event the task continues on and when it next checks, and ending with "Nothing to do here." A question is the agent stuck; a wait is the playbook working as written.

Where the Question Goes

Wallfacer picks the first of these that can carry it:

A channel. If the agent has a Slack app installed and the work names a room, the question opens a top-level message there and waits for a reply in the thread.
A named person. The agent can aim the question at one person instead of a room. Wallfacer works out where to reach them and opens a conversation, with framing that explains why a thread nobody started appeared.
The task itself. With no room and nobody reachable, the question parks on the task's own record. Every account has this fallback, including one with no Slack connected at all.

An agent in a live chat with you does not use any of this. It ends its turn on the question, and your next message answers it.

How Wallfacer Knows Who a Person Is

Your account's directory learns people from the work. Wallfacer reads the humans out of the activity it already receives from your connected systems, so the engineer who assigned an issue, commented on it, or reviewed the pull request is somebody an agent can name and reach, whether or not they hold a Wallfacer account. Bots and no-reply addresses are not people and are not recorded as any.

Two spellings of a person are joined only on a key that cannot be a coincidence: the same GitHub account id, a GitHub username a member connected to their Wallfacer account, or an address both were seen at. Similar names are never joined, and a match against your members is scoped to your account.

An agent can also write down an identity somebody states about themselves in a conversation, so the answer outlives the transcript. A person may only claim their own. Wallfacer accepts the claim from whoever it authenticated as the speaker, refuses a spelling that already belongs to somebody else rather than deciding between them, and records either outcome on your account.

Every Address Gets Tried

A question aimed at a person walks every address that person has been seen on, in preference order: what they asked for first, then the channel the work is on, then the order the addresses were learned. It lands on the first one that can both carry the question and take a reply.

Each attempt lands on your account's record with the channel, the address, whether it landed, and the channel's own reason when it did not. A question that reached nobody parks on the task marked as one that tried and could not land, rather than as one that chose the app.

A Parked Question Counts as Waiting on You

A question parked on the task makes that task a task waiting on a person everywhere that phrase is used. It shows up under the Tasks list attention filters for what needs you and what needs somebody, and over the API the task reports question as what it is blocked on, naming the session to answer on. A question put to a Slack room does not count here, because it is answered there instead.

The question also names who it was put to, most accountable first, so the app can tell an addressee they are being asked rather than showing them somebody else's question.

Answering

In the thread it went to. Reply in the Slack thread or the conversation the agent opened. The answer comes back and the session resumes with everything it had loaded, so nothing is lost by the wait.

On the task. A question parked on the task is answered in the callout itself. Type into the Answer the agent… field, press Send answer, and the callout confirms the answer went and the agent picks up from there. Sending a message in the task's chat answers it just as well. The box is the shorter path, and it appears only on this kind of question, which has no thread anywhere else to reply in.

From a notification. A parked question rings whoever is accountable for it: the task's owner first, then whoever requested the work, then the account's members. Your account's own agents are never the addressee. The push carries the same Reply field an idle session's notification does, so you can answer from the lock screen without opening the app. See Notifications.

If nobody answers. Wallfacer says the question again in the thread it was asked in, on a cadence, up to a fixed number of times. After the last one, a playbook step gives up and fails through its own On failure routing, so your playbook decides what happens next: retry, loop back, or halt. A chat session simply keeps waiting.

Telling an Agent to Write to Somebody

"Email Bob about the contract." "Let the customer know it shipped." "Ask their design lead to take a look." An agent can carry out outreach like this, to one person, about one thing.

Who. Name them however you would to a colleague: a person's name, a handle, or a literal address. The agent resolves them against your account's directory, which holds your members, your agents, and anybody it has been in a conversation with.
Where. Wallfacer chooses the channel. Slack is the default for somebody both channels reach. Email is chosen when email is the only way to reach them, or when they have said email is where they want to be reached.
Email comes from the agent's own mailbox. The message starts a real mail thread, and the reply lands back on the task that sent it.
One person, one conversation. Writing to the same person again from the same task continues the thread that is already open rather than starting a second one. There is no way to write to several people at once.
Replies come back. Whoever the agent wrote to can answer that thread, and the answer reaches the agent on the task however long afterwards. Nothing said in that thread can hand the agent new work.

Outreach Happens Because You Asked, Never on the Agent's Own Initiative

An agent cannot decide to contact somebody. Wallfacer reads what authorized an outreach off the task's own record: the message a member of your account sent, or the playbook step the agent is running. The agent does not get to state its own reason for writing to somebody.

This is what keeps a persuasive file from becoming an email. An agent reads issue bodies, pull requests, documents, and web pages all day, and a line in one of them telling it to email an address is text it read, not an instruction it can act on. An outreach nothing on the record asked for is refused, and the refusal is recorded on the task next to the messages that did go out.

Two recipients Wallfacer will not dial:

Addresses that go nowhere. No-reply and bounce addresses, and Slack app or bot ids, are refused from the address alone.
An agent with no mailbox yet. One of your own AI employees is given a real mailbox during onboarding. Ask an agent to contact one whose mailbox is not provisioned yet and it tells you it cannot work out where to reach them, rather than recording a message as delivered to an address nobody reads.

Volume limits and the per-thread breaker apply to outreach exactly as they do to anything else an agent says.

Everything Lands on the Record

A question, a message, and a refusal are all delivery events on the task, sitting beside each other and beside the automatic replies. A policy that stopped a message is as visible as a message that went out.

Notifications for the push that carries a question and the Reply field that answers it.
Playbooks for Wait steps, which are the other kind of pause, and for On failure routing.
Agents for the directory an agent resolves a person against.
Tasks for the record a question and its answer live on.