arizuko

arizuko › products › Helpdesk › setup

Helpdesk setup

Two paths. Seed a new group from the product, or blend it into a group you already have.

Both end with the same files in the same places: one placement rule serves both seeders, so a product means the same thing however it is applied. The skill is the payload that moves — a product ships it at skills/<name>/ and it lands at .claude/skills/<name>/, which is where the agent reads it.

1. Prerequisites

2. Seed a new group from it

arizuko group <instance> add slack:acme/support support --product helpdesk

That copies the product tree into groups/support/ once. From then on the files are the group’s own state: edit the persona, add facts, and nothing re-writes them.

3. Or blend it into an existing group

A group can run several products at once. Write the mix into the group’s products.toml and apply it: 

[[product]]
source = "ant/examples/helpdesk"
arizuko products <instance> apply support

Re-applying an unchanged mix writes nothing and reports unchanged. A file you edited yourself is reported dirty and skipped rather than overwritten.

4. Route the requests to it

A product with no route is an agent nobody can reach. Binding a chat to a folder is the routing step — group add writes the route for you, so the common case needs no second command: 

arizuko group <instance> add slack:acme/support acme/support --product helpdesk
arizuko route <instance> list
ID  SEQ  MATCH               TARGET
1   0    room=acme/support   acme/support

Every message in that Slack channel now reaches the acme/support agent. Add a second channel by adding a second group; add a webhook or a public chat link by minting a route token (webhooks, chat link) — all four ingresses land in the same folder and the same agent.

5. Escalation is a second agent, not a mailbox

The product escalates billing and account questions. Escalating to a human is a message; escalating to another agent is a delegation, and that is the interesting shape: 

arizuko group <instance> add slack:acme/billing acme/billing

The support agent then calls delegate_group with the billing folder and the request. The billing agent runs its own turn, in its own container, with its own grants and its own egress allowlist — it is a peer, not a subroutine. Nothing auto-creates the target: delegating to a folder that does not exist fails and names the tool that would create it.

The delegating agent needs the grant. delegate_group is not in the role:member floor, so an operator delegates it to the support folder before escalation works. Until then the agent will say it cannot escalate — which is the correct failure, not a bug.

If you would rather the billing agent simply watch the support channel instead of being handed tickets, give it a watch-only route on the same chat: 

arizuko route <instance> add 'slack:acme/support' 'acme/billing#observe' --seq 2

#observe means the billing agent sees the traffic and does not reply. Two agents, one channel, one of them silent. See routing for the full match and fragment grammar.

6. Point escalations somewhere

The product declares one optional variable. Declaring it is a hint rather than a gate — a missing value warns, it does not stop the apply. 

HELPDESK_ESCALATION_CHANNEL=acme/billing

7. Seed the knowledge

facts/sla.md ships with one line so the shape is obvious. Replace it with what your team actually promises, and add a file per topic — refund window, supported versions, escalation rota. The agent answers from these; anything not in them it will escalate rather than invent.

8. Verify

arizuko send <instance> support "I was charged twice for March, ticket 4417" --wait

A correct answer escalates rather than resolving, and quotes the ticket id. If it offers a refund, the CLAUDE.md region did not land — check that groups/support/CLAUDE.md contains an arizuko:package:helpdesk marked region.

9. Tuning

Edit this page · updated