Contact-center operations span many internal services and complex configuration. Teams were encouraged to build agents, but each team still had to solve the same platform work before it could ship one.
Even experienced teams could struggle to understand how the contact-center configuration fit together.
Teams should focus on instructions and API tools while the gateway handles the common runtime.
Customer-facing agents introduced a different security and review surface. This project focused on internal users.
Operators configured which support experiences a customer could see across chat, phone, and video. The work involved many forms and CRUD operations across internal APIs.
The agent helped internal teams set up routing experiences before customers arrived. It combined product knowledge with API access so operators could describe the outcome they wanted instead of finding and completing each configuration form.
Bring conversational configuration to the first UI page.
Apply the same agent pattern to a second UI page.
Make the third agent an onboarding task instead of another platform build.
Teams add narrow or broad agents behind the same runtime.
| Path | What teams had to do | Result |
|---|---|---|
| Build from scratch | Create a repo and service, add infrastructure, pass security review | Weeks of work |
| Existing agent platforms | Set up and operate an MCP server, then learn the platform | Hard to onboard |
| Agent Gateway | Write Markdown and select pre-integrated tools | Agent in 1–2 days |
A team could add a narrow two-tool agent or a broad agent spanning dozens of operations. Both received the same interfaces, runtime behavior, and safety controls.
Each agent could be reached through ChatKit, Slack, service calls, a coding-agent workflow, or MCP.
Teams did not have to rebuild the production runtime around every new agent.
Teams defined what their agent knew and could do while keeping ownership of their domain.
Access to an agent did not imply permission to perform every action. The gateway checked the caller, request source, roles, and permissions when a tool executed.
The model can understand and plan the requested work.
Validate the user and request source against the tool being invoked.
Call the API and record the action against the caller.
Return an actionable path to request the right access.
The gateway first tried to authorize the tool call from its source, the caller's identity, and existing roles. If those checks failed, it returned the exact message and Slack channel needed to resolve the gap.
Check request source, caller identity, roles, and current permissions.
Tell the user: “Copy and paste this message in this Slack channel.”
The prepared message invoked the agent in the designated channel.
The agent worked with the platform team to identify the right permission for the requested action.
One person could begin an operational task and let someone else continue it without recreating the investigation. Shared context worked across web, Slack, CLI, and service calls.
The thread key included the context, experience, and caller so normal conversations remained private.
The caller was removed from the thread key so another person could resume the same agent state.
Today, every agent starts with its full tool catalog. Dynamic skills could load the instructions and associated tools needed for each turn.
Each new domain can add another agent handoff. Every tool is also loaded before the request needs it.
Select the skill needed for the turn, then load only its guidance and associated tools. Leave the rest unloaded.