AI agents built to only answer inbound prompts degenerate into ambient noise when nobody sets up the proactive surface deliberately. This post covers the pattern the Orbit Agent Hub ships for the opposite case: scheduled, proactive outreach routed through the AI-agent runtime, observable in a dedicated tab, with the tenant-owned consent and quiet-hours controls applying at dispatch. All of the following exists assuming your tenant already has agents and CDP segments set up; nothing here configures a new surface.
Why outbound AI agents degenerate to ambient, without a proactive surface
The control case for "ambient" agents is a system with no proactive lane at all. Inbound-only agents wait to be triggered — the agent runtime spins up only after a customer on SMS, WhatsApp, or email starts a conversation. Every subsequent decision in that loop is downstream of the caller's choice to reach out.
Strip away the deliberate plumbing for outbound and the degenerate pattern is a different kind of ambient: every contact moves through journeys and ad-hoc blast sends rather than through an agent at all. The CDP still fires its events, the segments still drift, but the outbound surface exists as schedule-driven batch sends the agent never sees. Without the pattern that follows, the agent looks ambient in the wrong sense — present on the AI stack, never consulted, and never accountable for a single send decision.
The named failure modes teams actually see are: a segment that has been quietly accumulating a cohort for weeks with no send tied to the crossing, a scheduled campaign the operator cannot link back to any decision trail, and "why did the agent reach out" questions that have no per-event answer. The proactive-outreach tab exists because that last question deserves a first-class answer.
The ambient-outreach model: scheduled outreach through the AI-agent runtime
When a tenant binds an AI agent to a CDP segment, the trigger chain changes. A contact's entry into the segment no longer means "drop them into the next batch send" — the crossing triggers the agent runtime directly. The bound agent evaluates the specific contact in context and returns one of three outcomes per event: send, agent-declined in favor of a quieter choice, or blocked by a tenant policy. Each outcome is recorded with the agent id, the segment id, and the channel.
That per-event decision layer is the piece that keeps the tab from being a vanity rollup. The agent runtime persists the decision at trigger time, not after the fact, and the audit trail the Orbit Agent Hub surfaces reads it back. If the agent declined, the specific rule or reason that drove the decline is on the entry. If the policy blocked the send, that outcome is visible as its own category rather than a generic "filtered out" line.
The flowing-from-the-trigger design also determines what the surface does NOT do: it does not schedule a send from the UI alone, bypass the agent runtime by marking a contact as eligible, or start an outbound attempt outside the tenant's configuration. The tab is read-only. It gives operators oversight over what the ambient lane decided; it is not the place where a human schedules a campaign.
Consent, quiet hours, and opt-out apply — the tenant owns the rule
Proactive outreach runs on the same tenant-owned compliance rails as every other attempt in Orbit, because the surface rides them rather than replacing them. Consent posture governs whether a contact can be reached at all, quiet hours apply at the point the dispatch actually fires, and an opt-out is terminal until the contact opts back in. The agent does not override it, and the tab does not claim eligibility a tenant has not earned.
The operator configures those controls per tenant, per segment, and per channel per the compliance controls reference. Every ambient send evaluates at dispatch, so the quiet-hours gate that governs SMS send-time optimization applies here too. Contacts whose consent or reachability makes a specific channel ineligible send through their second-preference channel when a channel chain is configured and marked as such on the entry.
One caveat worth staining the wall in bright letters: the tab never reports a contact as "eligible." Eligibility is a dispatch-time computation owned by the tenant's configuration, not a label the runtime stamps on a row. The audit trail records the outcome of the decision, not a promise of future reachability.
Where it lives: the Proactive Outreach tab on the Agent Hub
The surface lives in the Agent Hub at /agents?tab=ambient-outreach. The tab is first-class on the Agents page rather than a stand-alone page, which is why the dedicated /agents/ambient-outreach route redirects into the tab — the capability is the tab content, not a separate destination. From it you read the sent / agent-declined / blocked rollup per agent, filter the full audit trail by outcome, and trace back to a specific contact or segment through the context each entry carries. The audit row is rendered directly in the Agent Hub and reads back identically from the underlying query surface.
The agent bindings themselves — which agents the tenant binds to which segments — live on the segment side and in the messaging-control plane, not in the Agent Hub. The tab surfaces the shadow those bindings cast.
---
For the read-only per-event trail and rollup, see the Proactive Outreach tab on the Orbit dashboard and the compliance send-gates reference. Proactive outreach ships on all Orbit plans.