Oracle AI Agent Studio Channels
Oracle AI Agent Studio channels are the messaging surfaces where users interact with a Fusion agent from outside the Fusion application itself. Oracle documents two of them: Slack and Microsoft Teams, both delivered in release 26A. A channel lets an employee ask an agent a question or trigger an action from the collaboration tool they already use, while the agent continues to run inside Fusion under the same identity, roles, and data-security rules.
This page explains what a channel is, which channels Oracle ships today, how they are configured, how access and security carry across them, and how to test agent behaviour on each surface. It sits under the Oracle AI Agent Studio overview and links back to the broader Oracle AI hub.
Last reviewed: 19 July 2026
Scope note — channels vs connectors. There is a genuine overlap here, and it is worth being honest about it. A channel is the surface a user reaches an agent through (Slack, Microsoft Teams). The Slack and Teams connectors — the client connector tools that technically link Agent Studio to those platforms — are covered on the Oracle AI Agent Studio connectors page. In practice a Slack or Teams channel is delivered through its connector, so the two topics touch. This page focuses on the user-facing channel experience, access, and testing; the connectors page focuses on the connector tool type and its configuration. Channels also relate to the broader external agent access model, which covers reaching agents programmatically outside Fusion.
What Is an AI Agent Studio Channel?
A channel is a supported external surface where a user can hold a conversation with an agent built in AI Agent Studio. Instead of opening the Fusion application to invoke an agent, the user types in a Slack message or a Microsoft Teams chat, and the request is routed to the agent, executed inside Fusion, and answered back in the same conversation. The channel is the delivery path; the agent, its topics, tools, and knowledge sources still live in AI Agent Studio.
This matters because most enterprise users spend their day in a collaboration tool, not in an ERP or HCM screen. A channel meets them where they already work, and the agent that answers is the same one that would answer inside Fusion — not a second, separately governed agent. AI Agent Studio itself has been generally available since release 25C; channels are a more recent addition, with Slack and Microsoft Teams both introduced in 26A. Oracle does not document additional named channels in the sources reviewed here, so this page names only Slack and Teams and treats "channel" generically otherwise.
Available Channels
Oracle documents two channels for AI Agent Studio. Both are labelled Generally available (release 26A) in Oracle's readiness material.
Slack
Generally available — release 26A
Publishes a Fusion agent as a Slack app so users can converse with it in a Slack workspace. The conversation is routed to the agent in Agent Studio, executed under the user's Fusion identity, and answered in Slack. Setup is documented in Oracle's Slack channel readiness note.
Microsoft Teams
Generally available — release 26A
Publishes a Fusion agent into Microsoft Teams so users can interact with it from a Teams chat. As with Slack, the agent runs inside Fusion; Teams is the surface. Oracle provides a Teams channel readiness note describing enablement and setup.
The two channels are functionally comparable from the agent's point of view — the same agent, topics, and tools serve both. What differs is the platform-side app registration and the steps needed to connect each collaboration tool to Fusion. Reaching an agent from a custom application rather than a chat tool is the external access path, not a channel.
Channel Comparison
A side-by-side view of the two documented channels. Confirm current details against Oracle's readiness notes before you enable either.
| Channel | Availability | Setup notes | Access / security notes |
|---|---|---|---|
| Slack | Generally available (release 26A) | Publish the agent as a Slack app and connect the workspace to Fusion via the Slack connector; follow Oracle's Slack channel readiness steps. | Requests run under the user's Fusion identity; the agent enforces the same roles and data security as in Fusion. Map Slack users to Fusion users and confirm approval gates still apply. |
| Microsoft Teams | Generally available (release 26A) | Publish the agent into Teams and connect via the Teams connector; follow Oracle's Teams channel readiness steps. | Same as Slack: Fusion role-based access and data security apply to every request. Verify identity mapping and approvals on the Teams surface specifically. |
| Other surfaces | Not documented as named channels (confirm with Oracle) | Oracle names only Slack and Teams. For programmatic invocation from custom apps, use external REST access, not a channel. | External invocation carries its own identity, token, and audit model — see the external access page. |
Configuring a Channel
Exact screens change between releases, so treat the following as a generic sequence and confirm each step against Oracle's current Slack and Teams readiness notes rather than a fixed screen path.
Typical channel enablement sequence
- 1. Prepare the agent. Build and validate the agent in AI Agent Studio first — its topics, tools, instructions, and knowledge sources should already behave correctly inside Fusion before you expose it on a channel.
- 2. Register the platform app. Create the corresponding Slack or Microsoft Teams application on the collaboration platform side, per Oracle's readiness instructions.
- 3. Connect via the connector. Link the platform to Fusion using the relevant client connector. Configuration of the connector tool itself is covered on the connectors page.
- 4. Publish the agent to the channel. Make the agent available on Slack or Teams so mapped users can start a conversation.
- 5. Map identities. Ensure channel users resolve to the correct Fusion users, so role-based access is applied to each request.
- 6. Confirm approval behaviour. Where an agent action requires human approval, verify the approval step still fires when the request originates from a channel.
- 7. Test and roll out. Exercise representative conversations on each channel before wider release.
Access Control Across Channels
A channel does not grant new access — it exposes an agent that already has a defined scope. When a user talks to an agent from Slack or Teams, the request should be tied back to that user's Fusion identity, and the agent should act only within the roles and privileges that identity holds. Two people asking the same agent the same question can legitimately get different answers if their Fusion data access differs, and that is correct.
Identity mapping is therefore the control point: if channel users are not resolved to the right Fusion users, access control cannot be enforced. Confirm what happens for a user who exists in Slack or Teams but has no matching Fusion account, or whose account lacks the roles the agent's tools require — the expected outcome is a denied or empty result, not a fallback that leaks data.
Because the same agent is reachable from more than one surface, access should be verified per channel. A control that holds in Fusion, and even in Slack, is not automatically proven in Teams.
Security: An Agent in Slack or Teams Still Enforces Fusion Permissions
The most important security point about channels is also the most easily misread. Putting an agent in Slack or Microsoft Teams does not move it outside Fusion's security model. The agent continues to run inside Fusion, under the requesting user's identity, and it enforces the same role-based access, data security, and policy controls it would enforce in the Fusion application. The channel changes the conversation surface, not the permission boundary.
That said, a channel adds surface area. Requests now traverse a third-party collaboration platform, so the platform-side app registration, the connector configuration, and identity mapping all become part of the security picture. Any action an agent can take should still respect its human-approval requirements when invoked from a channel, and sensitive responses should not become visible to channel members who would not see them in Fusion.
Test the assumption, don't trust it. "The agent enforces Fusion permissions on Slack and Teams" is the intended behaviour, and it is the behaviour to verify rather than assume. Confirm that an unauthorised user is refused, that approval gates fire, and that no data appears on a channel that the user could not see in Fusion.
Testing Agents Across Channels
Because the same agent behaves differently depending on who asks and where they ask from, testing should be repeated on each channel rather than assumed to carry over. A practical channel test checklist:
- Functional parity. The same prompt produces an equivalent answer in Fusion, Slack, and Teams for an authorised user.
- Identity mapping. Channel users resolve to the correct Fusion identity; unmapped users are handled safely.
- Access enforcement. A user without the required role is refused the same way on each channel.
- Human-approval gates. Actions that require approval still prompt for it when triggered from a channel.
- Data exposure. No response reveals data on a channel that the user could not see in Fusion.
- Conversation handling. Multi-turn context, errors, and timeouts behave acceptably on each surface.
- Regression after updates. Channel behaviour is re-checked after each Oracle quarterly update and after any connector or agent change.
This channel-specific checking complements, rather than replaces, broader agent validation. Testing the agent's underlying topics, tools, and prompts is a separate discipline; here the added dimension is simply the surface the user reaches the agent through.
Release Status
Both documented channels arrived in the same quarter:
| Capability | Status | Release |
|---|---|---|
| AI Agent Studio (product) | Generally available | 25C |
| Slack channel | Generally available | 26A |
| Microsoft Teams channel | Generally available | 26A |
Availability and behaviour can change between quarters, so treat the readiness notes linked below as the authoritative source and re-confirm before enabling a channel in production.
How SyntraFlow Helps
SyntraFlow is an Oracle Fusion testing and release-intelligence platform, not a part of Oracle AI Agent Studio. Where an organisation is exposing agents on Slack or Microsoft Teams, SyntraFlow can be configured to help teams plan and evidence the validation work around those channels — for example, a repeatable checklist of access, approval, and data-exposure cases run on each surface and re-run after quarterly updates.
SyntraFlow helps organisations assess whether channel access still lines up with Fusion role-based security after configuration changes, and its release intelligence can connect knowledge of an Oracle quarterly update with a targeted re-test of agent channels. These are complementary activities — SyntraFlow does not enable, host, or replace Oracle's channels, and does not guarantee any specific agent outcome. See the Oracle ERP testing tool for how SyntraFlow approaches Fusion test automation more broadly.
Official Oracle References
The authoritative Oracle sources for AI Agent Studio channels. Always confirm current details against these:
- Slack channel — 26A readiness: docs.oracle.com/…/26A-common-wn-f43243.htm
- Microsoft Teams channel — 26A readiness / setup: docs.oracle.com/…/26A-common-wn-f42115.htm
- AI Agent Studio key capabilities: docs.oracle.com/…/aiaas/key-capabilities.html
- Oracle Fusion AI product page: oracle.com/applications/fusion-ai/
Related Oracle AI Pages
Channels sit next to several closely related topics. Go deeper:
AI Agent Studio ⭐
The parent overview of Agent Studio.
Agent Studio Connectors →
The Slack/Teams client connectors behind channels.
External Agent Access →
Reaching agents programmatically outside Fusion.
Human Approval Gates →
Approval steps before an agent acts.
Oracle AI Hub →
The full Oracle AI content hub.
Oracle ERP Testing Tool →
SyntraFlow's Fusion test automation.
Frequently Asked Questions
What channels does Oracle AI Agent Studio support?
▼
Oracle documents two channels for AI Agent Studio: Slack and Microsoft Teams, both generally available in release 26A. These let users interact with a Fusion agent from a collaboration tool. No other named channel appears in the Oracle sources reviewed here; confirm current availability with Oracle before assuming a third surface.
When did Slack and Teams channels become available?
▼
Both the Slack channel and the Microsoft Teams channel are documented as generally available in release 26A. AI Agent Studio itself has been generally available since 25C. Oracle's Slack and Teams readiness notes are the authoritative source for enablement details.
How is a channel different from a connector?
▼
A channel is the surface a user reaches an agent through — Slack or Teams. A connector is the client connector tool that technically links Agent Studio to that platform. The two overlap because a channel is delivered through its connector. The connector tool configuration is covered on the Agent Studio connectors page; this page covers the user-facing channel experience, access, and testing.
Does an agent in Slack or Teams still enforce Fusion security?
▼
Yes — that is the intended behaviour. The agent runs inside Fusion under the requesting user's identity and applies the same role-based access and data security it would in the Fusion application. The channel changes the surface, not the permission boundary. Because it is intended behaviour, it is worth verifying rather than assuming, especially for unauthorised users and approval gates.
Do human-approval steps still apply on a channel?
▼
They should. An action that requires human approval before it executes is expected to still prompt for that approval when the request originates from Slack or Teams. This is a key case to confirm during channel testing. See human approval gates for how approval works.
Is a channel the same as external REST access to an agent?
▼
No. A channel is a human conversation surface (Slack, Teams). Reaching an agent programmatically from a custom application is a different mechanism with its own identity, token, and audit model, covered on the external agent access page. Use a channel for user chat and external access for app-to-agent invocation.
Why test the same agent on each channel separately?
▼
Because behaviour that holds in Fusion, or even in Slack, is not automatically proven in Teams. Identity mapping, access enforcement, approval gates, and data exposure can differ by surface, and platform-side setup adds variables. Re-verifying each channel — and re-testing after quarterly updates — catches drift that a single-surface test would miss.
Can SyntraFlow test Oracle AI agents on Slack and Teams?
▼
SyntraFlow can be configured to help teams plan and evidence the validation work around channels — access, approval, and data-exposure checks run per surface and repeated after updates. It helps organisations assess whether channel access still aligns with Fusion security. SyntraFlow does not enable, host, or replace Oracle's channels, and makes no guarantee about a specific agent's behaviour.
Assess Your Oracle AI Agent Channels
Understand how Slack and Microsoft Teams channels expose your Fusion agents, where access and approval controls need verifying, and how to keep them tested through Oracle's quarterly updates. Talk to SyntraFlow.