Bring your client into your tasks: answers straight from the source

A client answers an agent's question in a shared task that the agency team works from, instead of calls and emails.

The answers are with the client

Every agency knows this task. The client writes one line: "Let members pause their membership when they travel." The team can't build it yet. Pause for how long? Who switches it on? What happens to the classes already booked?

Only the client knows. So the questions go on a journey.

Before: questions on a relay

The project manager collects questions from the designer and the developers and books a call for Thursday. On the call the client answers most of them while the PM takes notes. The PM writes a summary email. The client replies the next day with "one more thing" in a messenger. A week later a developer asks something nobody thought of, and the round starts again.

By then the answers live in four places: call notes, an email thread, a chat and someone's memory. The task still says "Let members pause their membership when they travel."

After: the client answers in the task

CRUX is the workflow layer between your tracker and the AI agents your team already uses. Some of those agents are advisors: chat agents for people who work with the text of tasks rather than code. You can read about them in AI agents for the rest of the team: PMs, QA and clients.

One of them interviews people about a request in plain business language. Normally a PM sits in that chat and relays questions to the client. But the client can sit there themselves.

Here is how it goes for an invented example: an agency building a booking app for a small chain of yoga studios. Olena owns the studios. She opens the task's chat with the interview agent:

Agent: Your request says "pause their membership". I read that as: for a while the member doesn't pay and can't book classes, and the missed days are added at the end. Is that right?

Olena: Yes. They shouldn't lose the days they paid for.

Agent: It says "when they travel". Is travel the only reason, or can members pause for any reason, like illness? My guess is any reason.

Olena: Any reason. But no more than 30 days a year in total.

Agent: Who can switch the pause on: the member, or staff at the front desk?

Olena: Both. Some of our older members just phone the studio.

Agent: What happens to classes already booked during the pause? My guess: they are cancelled and the member is told.

Olena: Not sure. Two studios charge for late cancellations. I'll ask the managers.

Agent: I'll mark that as open. Here is the draft for the task. Should I post it?

Olena: ok

One question at a time, each tied to her own words, each with a suggested answer she can simply confirm. No technical terms: this agent asks what the request means, and the design and technical questions come later, from other agents talking to the team.

Nothing reaches the task until she says "ok". Then the answers are posted as an artifact, a structured comment:

ARTIFACT: domain-qa v1 (approved in chat)
Q1 "pause": no payment, no bookings; missed days are added at the end.
Q2 "when they travel": any reason; at most 30 days a year in total.
Q3 Who: the member, or front-desk staff on their behalf.
Gaps: classes already booked during a pause. Waiting for the
studio managers (late-cancellation fees differ between studios).

The open question isn't hidden or guessed. It sits on the task where everyone can see it, and when Olena comes back with the answer, the agent posts a version 2.

The next morning the agency's PM reads the artifact on the task. It is what the team needs, so the PM moves the task on to design and the technical interview. The designer, the developers and their agents all start from Olena's own words. Nothing was retyped from call notes.

"Where are we?" in plain words

The other half of a client's questions is about progress. Instead of waiting for the weekly update, a client can ask an advisor.

Our default workflow has a status-report agent. It reads the board: what's done, what's in progress, what's next and what is blocked. It turns that into a short update in client language, without tracker jargon, and it never claims anything the board doesn't show. An advisor that can read the project's wiki, and the code if you allow it, can also explain how a feature works today, in plain words. The client doesn't need to read any code. (How the wiki stays current is in Our project wiki: memory that AI agents can read and write.)

How a client gets in

There is no special client mode. The client joins like any teammate:

  1. An admin of your organization in CRUX invites them by email with the member role. They sign in with a link sent to their email; there is no password.
  2. A project admin adds them to their project only. A member sees only the projects they were added to.
  3. The client connects their own account in your tracker, once. CRUX agents always act in the tracker as the person who is chatting, so the client needs a seat there. A good side effect: the answers on the task appear under the client's own name.

Inside the project, a member sees what other members see: its tasks and its agent chats. If your team needs a place for internal-only discussion, keep it outside that project.

What stays with the team

Bringing the client in doesn't hand them the steering wheel:

  • Advisors only read the code and the wiki. No advisor, whoever chats with it, can change them.
  • The workflow is the team's. Which agents exist, their prompts and their skills are edited by project admins. A member can only view them.
  • Nothing is posted without approval. The agent shows a draft and posts only after an explicit "ok".
  • Agents never move tasks. Moving a task to the next status is a person's decision, and in our example that person is the PM.
  • Chats don't last forever. They are deleted after a period the team sets. The approved artifact on the task stays.

For founders and for agencies

If you are the client, you don't have to hand over your idea and wait for a demo. You can shape it together with the people building it and their AI agents, in the same tasks, and check where things stand whenever you like.

If you run an agency, the relay goes away. Questions don't wait for the next call, answers don't get lost in an email thread, and the PM's job shifts from carrying messages to checking that the recorded answers make sense.

In short

  • The client works in the same tasks as your team.
  • An advisor asks them one plain question at a time and records the approved answers on the task.
  • The client can ask an advisor where the project stands, in plain words.
  • The client joins as an ordinary member of one project, with their own tracker account.
  • The code, the wiki, the workflow and the decision to move a task on stay with the team.
All articles