Aria: agents with a branch context

A named layer, because operators should know what is acting

Software that acts on your behalf should have a name, a scope, and a record. Aria is the agent layer of the shared platform — the part that reads authorized operational state, proposes actions, and executes the bounded set that policy and approval gates allow. It is named because "the automation did it" is not an acceptable entry in an audit trail.

Branch-aware means context is carried, not inferred

Every Aria action runs inside a branch of your hierarchy: a specific brand, and where relevant a specific region, location, or department. That context comes from the invoking session and the workflow definition — never inferred from a URL, a prompt, or whatever the agent happened to look at last.

The practical consequence is the one our isolation model promises everywhere else: an agent working a location's queue sees what an operator at that location may see, and nothing more. There is no broader "agent context" shadowing the real permission system. If a workflow needs more scope, the grant changes — explicitly, reviewably — rather than the agent quietly reaching further. The required boundaries are enumerated at governed agent boundaries.

Outreach is policy-gated by default

Messages that leave the building are the clearest case for gating, because they cannot be unsent. Aria's outreach — follow-ups, reminders, re-engagement — is evaluated against policy before anything is drafted, let alone sent:

• Consent and suppression state is checked first. No policy-compliant path messages someone who has opted out.
• Quiet hours and frequency limits are operator policy, not vendor defaults buried in a model.
• Content classes are constrained by workflow. A renewal reminder workflow drafts renewal reminders.
• Send authority follows the action's consequence. Routine, reversible classes can run inside policy; anything sensitive routes through a named human gate, and the gate decision is recorded either way.

Lead engagement at a designed-for sub-60-second pace

Inbound leads decay. Everyone in a business that receives them knows the shape of that curve even if the exact numbers differ. Aria's lead-engagement workflow is designed for a sub-60-second first response to an inbound inquiry: acknowledge, qualify against the operator's criteria, and route to the right surface or person with the context attached.

Two honesty notes belong with that sentence. "Designed for" is a design target for the first automated touch — not a guarantee, not an SLA, and not a number we will put in a contract. And the pace comes from structure, not recklessness: drafting at machine speed is the easy part; drafting inside policy, with the right brand context, with gated send authority and a complete record, is the actual engineering. The second part is where the work went.

New workflows earn pace gradually. The adoption path we recommend is proposals first: Aria drafts, operators review, nothing sends. When proposal quality holds up under review, execution opens for the bounded action classes policy allows — and the gates stay in front of anything irreversible.

The record is the product

Every Aria action leaves the same durable trail the rest of the platform produces: what was observed, what was proposed, which policy applied, who or what approved, what executed, and what happened. Denied proposals are kept too — they are often the most instructive entries, because they show the boundary working before something expensive happened.

What we will not claim

We will not claim autonomy beyond bounded, gated workflows, and we will not publish engagement metrics we have not earned the right to share. The claim is architectural: agents that carry your branch context, act inside your policy, and leave a trail your counsel can reconstruct.