Packaging the Platform in Cortana

Chapter 8 · 10:21–11:34

The platform becomes useful to employees only when its capabilities are easy to reach. In this chapter, the speakers present Cortana as that access layer: a company assistant available through Slack, the command line (CLI), and a web interface.

Cortana does not replace the platform underneath it. It brings several earlier building blocks together:

Building block	Role in the composed assistant
Skills	Reusable procedures that guide how a task is performed
MCPs	Interfaces to tools and services
Context graph	Relationship-aware context retrieval
Code access	Access to the code-related information needed for engineering work
DevPods	Prepared environments in which agent work can run
Cortana	The assistant and orchestration surface that connects these capabilities to people

The important distinction is packaging versus replacement. A person may see one assistant, but the assistant still depends on specialized foundations for tools, context, code, and execution.

The slide shown at about 10:34 connects Slack, the Web UI, and the CLI to the platform foundation. It makes Cortana's orchestration role visible.

One question can cross several platform layers

Consider a teaching example: an employee asks a code-related question in Slack. The message starts at a surface, meaning a user entry point. Cortana can then compose the capabilities needed to handle the request:

1. A relevant skill can provide the procedure for the task.
2. The context graph can help locate related services, owners, or other engineering context.
3. MCPs can expose the operations or services that the task requires.
4. Code access can connect the work to the relevant repositories or code information.
5. A DevPod can provide a prepared runtime when the work needs an execution environment.
6. Cortana can present the resulting interaction back through Slack, or through the CLI or web interface.

This is a conceptual teaching model of composition, not a claim that every question uses every building block. The useful point is that the employee does not need to manually assemble the platform for each request. Cortana is the common entry point, while the underlying layers perform their specialized jobs.

Personas customize behavior

Teams can configure personas with custom prompts and skills. A persona is a configured assistant role. Its prompts shape how it approaches a task, and its skills provide reusable guidance for carrying out that role.

For example, a team could define a persona for a domain-specific engineering procedure. When someone invokes that persona, Cortana has more than a generic request to help with code. It has team-specific guidance about how to organize the work.

However, a persona is not unlimited authority. Customizing behavior is different from granting access. A persona can describe how an assistant should work, but the platform still needs to control what the assistant is allowed to see or do. This separation prevents a friendly name or custom prompt from becoming an accidental permission system.

Question	Persona answers	Platform controls answer
How should the assistant approach this kind of task?	Yes: through prompts and skills	—
Which tools, code, or environments may it use?	Not by itself	Yes: through access and operational controls

This distinction matters as assistants become more specialized. A team can make an assistant more useful without assuming that specialization should also expand its authority.

Shared channels turn assistance into team work

Cortana is not limited to a private, one-person interaction. The speakers describe team collaboration through shared channels. A shared channel gives a team a place to see the request and the assistant's response together.

That visibility changes the workflow:

• A question does not have to remain in one person's private conversation.
• Other team members can inspect the context and continue the discussion.
• A persona's domain-specific behavior can become part of a repeatable team process.

The result is closer to a shared assistant than to a private chatbot. The channel becomes a visible coordination surface, while the platform foundation remains responsible for retrieval, tools, code access, and execution.

The frame at about 11:15 shows a Cortana interaction in a Slack-style surface. It supports channel-based assistant use. The frame alone does not establish that more than one human participant is present.

A team-persona example

Suppose a team wants its Slack assistant to follow a particular domain procedure. The team can configure a persona with a custom prompt and the relevant skill. A member then asks a question in the shared channel.

The persona supplies consistent guidance for the task. Cortana provides the access path to the platform capabilities. The shared channel lets the team inspect the interaction and add follow-up questions. These are three separate concerns:

1. Behavior: the persona expresses the team's preferred way of working.
2. Capability: the platform supplies context, tools, code access, and execution when needed.
3. Visibility: the shared surface lets the team participate in the workflow.

Keeping these concerns separate makes the design easier to reason about. A shared channel does not itself provide better context. A persona does not itself provide tools. A tool connection does not itself explain the team's procedure. Cortana packages the pieces so they can work together without making them the same thing.

Why this packaging matters

The earlier chapters describe powerful components in isolation. Cortana supplies the user-facing composition layer that makes those components reachable through familiar surfaces. This reduces the distance between a person's question and the managed capabilities that can help answer it.

The packaging also preserves useful boundaries:

• One interface does not mean one undifferentiated system. Skills, MCPs, graph context, code access, and DevPods retain different responsibilities.
• Customization does not mean unrestricted access. A persona changes instructions and procedures; it should not be treated as a blanket permission grant.
• Visibility does not mean correctness. A shared conversation makes work easier to inspect, but inspection is still different from validating the answer or approving an action.

This is the bridge from platform construction to the software-delivery walkthrough that follows. The next chapter starts with an idea discussed in Slack and uses Cortana to turn that discussion into business research.

Key takeaways

1. Cortana is the composition and access layer for Uber's agent platform.
2. It exposes skills, MCPs, graph context, code access, and DevPods through Slack, CLI, and web surfaces.
3. Personas customize an assistant with prompts and skills, but they do not automatically grant authority.
4. Shared channels make agent interactions available for team collaboration and inspection.
5. The assistant is simple at the surface because the specialized platform layers remain underneath it.