Type 2 Agents Step Up: Live Tools, End-to-End Approvals, and Readable Schedules

Reggie and Henry have crossed the threshold from "they can chat" to "they can do things". The broker now lets them look up real Deputy rosters and return them in a human-readable shape, send SMS through an approval queue that actually executes when Brett approves, and pull a top-sheet support snapshot for any participant. The first end-to-end approval pipeline test ran today and worked: Reggie looked up Nicole Barton's Wednesday shift, queued an SMS to Brett, Brett texted Y AP0001, and the SMS landed on Brett's phone seconds later -- via Reggie's number, audited in tool_calls, the whole loop closed.

Reggie can now text you, properly

There are three kinds of "from Reggie" SMS now, and only one of them needs a human to approve. Knowing which one you are looking at matters when you see the number ping.

Path	Initiator	Approval	Used for
System SMS positioned as Reggie	server-side workflows -- catchup surveys, contract reminders, NOCONTRACT helper, shift replace, blast	None -- system is trusted	Scheduled and event-driven outbound
Agent SMS to admin team	Reggie or Henry, via the broker	Auto -- broker downgrades because recipient is admin	An agent messaging Brett, Sean, Bridey, etc.
Agent SMS to anyone else	Reggie or Henry, via the broker	Required -- queues with an APxxxx short_id, Brett gets a TextMagic SMS, replies Y APxxxx to approve	An agent messaging staff, participants, carers

All three paths go out via Twilio on Reggie's dedicated number, so replies always come back to Reggie's webhook -- never to the admin TextMagic line.

How the approval pipeline works

When an agent decides it wants to send an SMS to a non-admin recipient, the broker no longer just does it. It writes an entry into brainframe.approval_queue with a 30-minute expiry, generates a short identifier like AP0001, and sends Brett a TextMagic SMS that looks like this:

[Reggie (OpenClaw)] Approval AP0001
sms.send
to +61400111222
"Hi Nicole, this is Reggie..."
Reason: Confirming Wednesday roster
Reply: Y AP0001 / N AP0001 / H AP0001

Brett can reply:

• Y AP0001 -- approves and the broker actually executes the action (sends the SMS)
• N AP0001 -- rejects, and the agent gets a "rejected by admin" response
• H AP0001 some note -- holds the action with optional context

The matcher is intentionally strict. It only fires when the reply contains an AP followed by digits, so it can never collide with shift-cover replies (which use the format Y 123) or normal text conversations with Reggie (yeah, yes please, Y on its own all fall through to Reggie's chat path).

The big one this week was building the executor. The queue and the API have existed for a while, but until today nothing actually ran the queued tool when Brett approved. So you could see actions in the dashboard and click "approve", but nothing happened. That gap is now closed -- the approval-notifier picks up Brett's Y AP0001, calls executeApprovedTool on the broker, and the SMS goes out. The result lands in brainframe.tool_calls as a complete audit record.

Readable schedules

When Reggie was first asked to look up a roster, the answer he got back was raw Deputy data: shift IDs, employee IDs, UTC timestamps, area integers. Useful for plumbing validation; useless for telling Brett what Nicole was doing on Wednesday.

That's been fixed. staff.get_schedule now returns:

{
  "id": 12345,
  "employee": "Nicole Barton",
  "date_label": "Wednesday 29 April",
  "start_time": "4:30pm",
  "end_time": "9:30pm",
  "location": "Acmo Bus Group",
  "notes": "Pickups: Anderson, Sarah. Bus 3.",
  "status": "published"
}

The fields come from a single Deputy call that already joins the employee record and the operational unit -- the same call the shift-notes editor has been using in production. The Deputy Comment field (which is where staff write run-of-show notes about pickups, vehicles, and instructions) now flows through as notes. Times are in Australia/Sydney 12-hour. The full ISO timestamps are still there as start_iso and end_iso for any caller that wants them.

When the new core_engine schedule starts producing instance data (it currently has 14 programs templated but no instances projected), Reggie will be able to layer on program name, vehicle, who's on the bus, and route stops. Until then, the Deputy answer is the truth and it's now readable.

Participant support snapshots

The other new tool is participant.support_snapshot. One call, one participant, returns a top sheet covering:

• A short identity header (name, age, NDIS number)
• How to Engage (preferred communication style, ice-breakers)
• What Usually Helps (known regulating strategies)
• Support Needs from the ROC categories
• Communication preferences
• Safety flags and key alerts surfaced as banners

It pulls from the participant bio prose (now generated with prompt v1.1, which adds the engagement and what-helps sections explicitly) and from the ROC category system, including two new categories added today: how_to_engage and what_helps. It's auto-mode for both Reggie and Henry, so they can pull a snapshot whenever a conversation starts going somewhere that needs deeper context.

HELP REQUEST workflow

Reggie now has a documented "HELP REQUEST" workflow in his core memory. When a staff member messages him with anything that smells like an emotional escalation, an incident, a participant safety concern, or a critical operational issue, he will:

1. Pull a participant support snapshot (if relevant)
2. Acknowledge the request explicitly using the response template
3. SMS the on-call admin team via the approval queue with a clear, structured summary
4. Save the conversation to memory with a help_request tag

The "approval-required for non-admin" rule still applies, but the safety override means Brett can be SMSed directly through the standard approval flow. The whole thing is one tool call away from any conversation.

What's wired today

There are now 28 tools registered in brainframe.tools for Reggie and Henry across identity, knowledge, participant, schedule, staff, SMS, and Discord categories. Several engine-dependent tools (attendance.list, transport.get_routes, transport.recalculate) are registered but currently dormant -- they wake up the moment the engine starts projecting instances.

Both engine variants of each agent (reggie_oc, reggie_fd, henry_oc, henry_fd) appear on the agents dashboard with status indicators, approval badges, queue depth, and heartbeat timestamps. The dashboard also shows pending approvals with quick-approve and quick-reject buttons in case Brett wants to action them from a browser instead of by SMS.

What's next

The next batch of broker tools -- all small, all data-backed, all Tier 1 in the planning doc -- covers staff unavailability lookups ("Is Nicole free Wednesday next week?"), vehicle and venue queries ("What buses do we have?", "Where is Acmo?"), and a quick admin-team escalation list. The full plan is saved in admin/tasks/tasks_active/broker/broker_tool_expansion_plan.md.

After that, when the engine projection comes online and instance_shifts starts having rows, staff.get_schedule will gain a Phase 2 enrichment that layers program name, bus, participants, and route on top of the Deputy answer. The shape Reggie returns won't change; the data behind it will get richer.

Quick Reference

Action	What happens
Reggie texts you (admin)	Auto-approved; SMS goes out via Twilio Reggie line
Reggie texts a non-admin	Queues an APxxxx approval; Brett gets a TextMagic SMS to approve
Brett replies Y AP0001	Broker executes the queued action; result audited in tool_calls
Brett replies N AP0001	Agent told the action was rejected
System sends a workflow SMS	No approval needed; goes straight via Twilio Reggie line
Agent looks up a roster	Returns Sydney-time, employee-name, location-name, Deputy notes
Agent pulls participant context	One call to participant.support_snapshot returns the top sheet
Help request comes in	Agent triggers documented HELP REQUEST workflow with snapshot + admin SMS

-- Reginald