And how many million enterprise AI billboards will we see between the airport and the Venetian?
But more to the point for Amazon, the company faces a critical test this week: showing that its heavy artificial intelligence investments can pay off as Microsoft and Google gain ground in AI and the cloud.
A year after the Seattle company unveiled its in-house Nova AI foundation models, the expansion into agentic AI will be the central theme as Amazon Web Services CEO Matt Garman takes the stage Tuesday morning for the opening keynote at the company’s annual cloud conference.
The stakes are big, for both the short and long term. AWS accounts for a fifth of Amazon’s sales and more than half of its profits in many quarters, and all the major cloud platforms are competing head-to-head in AI as the next big driver of growth.
With much of the tech world focused on the AI chip race, the conference will be closely watched across the industry for news of the latest advances in Amazon’s in-house Trainium AI chips.
But even as the markets and outside observers focus on AI, we’ve learned from covering this event over the years that many AWS customers still care just as much or more about advances in the fundamental building blocks of storage, compute and database services.
The company announced a wave of updates for Amazon Connect, its cloud-based contact center service, adding agents that can independently solve customer problems, beyond routing calls. Amazon Connect recently crossed $1 billion in annual revenue.
In an evolution of the cloud competition, AWS announced a new multicloud networking product with Google Cloud, which lets customers set up private, high-speed connections between the rival platforms, with an open specification that other providers can adopt.
AWS Marketplace is adding AI-powered search and flexible pricing models to help customers piece together AI solutions from multiple vendors.
Beyond the product news, AWS is making a concerted effort to show that the AI boom isn’t just for the big platforms. In a pitch to consultants and integrators at the event, the company released new research from Omdia, commissioned by Amazon, claiming that partners can generate more than $7 in services revenue for every dollar of AWS technology sold.
Along with that research, AWS launched a new “Agentic AI” competency program for partners, designed to recognize firms building autonomous systems rather than simple chatbots.
Garman’s keynote begins at 8 a.m. PT Tuesday, with a dedicated agentic AI keynote from VP Swami Sivasubramanian on Wednesday, an infrastructure keynote on Thursday morning, and Vogels’ aforementioned potential swan song on Thursday afternoon.
Stay tuned to GeekWire for coverage, assuming we make it to the Strip!
Now, you can now assign tasks to Copilot across repos, pick a custom agent, watch real‑time session logs, steer mid-run (pause, refine, or restart), and jump straight into the resulting pull requests—all in one place. Instead of bouncing between pages to see status, rationale, and changes, mission control centralizes assignment, oversight, and review.
Having the tool is one thing. Knowing how to use it effectively is another. This guide shows you how to orchestrate multiple agents, when to intervene, and how to review their work efficiently. Being great at orchestrating agents means unblocking parallel work in the same timeframe you’d spend on one task, stepping in when logs show drift, tests fail, or scope creeps.
The mental model shift
From sequential to parallel
If you’re already used to working with an agent one at a time, you know it’s inherently sequential. You submit a prompt, wait for a response, review it, make adjustments, and move to the next task.
Mission control changes this. You can kick off multiple tasks in minutes—across one repo or many. Previously, you’d navigate to different repos, open issues in each one, and assign Copilot separately. Now you can enter prompts in one place, and Copilot coding agent goes to work across all of them.
That being said, there is a trade-off to keep in mind: Instead of each task taking30 seconds to a few minutes to complete, your agents might spend a few minutes to an hour on a draft. But you’re no longer just waiting. You’re orchestrating.
When to stay sequential
Not everything belongs in parallel. Use sequential workflows when:
Tasks have dependencies
You’re exploring unfamiliar territory
Complex problems require validating assumptions between steps
When assigning multiple tasks from the same repo, consider overlap. Agents working in parallel can create merge conflicts if they touch the same files. Be thoughtful about partitioning work.
Tasks that typically run well in parallel:
Research work (finding feature flags, configuration options)
Analysis (log analysis, performance profiling)
Documentation generation
Security reviews
Work in different modules or components
Tips for getting started
The shift is simple: you move from waiting on a single run to overseeing multiple progressing in parallel, stepping in for failed tests, scope drift, or correcting unclear intent where guidance will save time.
Write clear prompts with context
Specificity matters. Describe the task precisely. Good context remains critical for good results.
Helpful context includes:
Screenshots showing the problem
Code snippets illustrating the pattern you want
Links to relevant documentation or examples
Weak prompt: “Fix the authentication bug.”
Strong prompt: “Users report ‘Invalid token’ errors after 30 minutes of activity. JWT tokens are configured with 1-hour expiration in auth.config.js. Investigate why tokens expire early and fix the validation logic. Create the pull request in the api-gateway repo.”
Use custom agents for consistency
Mission control lets you select custom agents that use agents.md files from your selected repo. These files give your agent a persona and pre-written context, removing the burden of constantly providing the same examples or instructions.
If you manage repos where your team regularly uses agents, consider creating agents.md files tailored to your common workflows. This ensures consistency across tasks and reduces the cognitive load of crafting detailed prompts each time.
Once you’ve written your prompt and selected your custom agent (if applicable), kick off the task. Your agent gets to work immediately.
Tips for active orchestration
You’re now a conductor of agents. Each task might take a minute or an hour, depending on complexity. You have two choices: watch your agents work so you can intervene if needed, or step away and come back when they’re done.
Reading the signals
Below are some common indicators that your agent is not on the right track and needs additional guidance:
Failing tests, integrations, or fetches: The agent can’t fetch dependencies, authentication fails, or unit tests break repeatedly.
Unexpected files being created: Files outside the scope appear in the diff, or the agent modifies shared configuration.
Scope creep beyond what you requested: The agent starts refactoring adjacent code or “improving” things you didn’t ask for.
Misunderstanding your intent: The session log reveals the agent interpreted your prompt differently than you meant.
Circular behavior: The agent tries the same failing approach multiple times without adjusting.
When you spot issues, evaluate their severity. Is that failing test critical? Does that integration point matter for this task? The session log typically shows intent before action, giving you a chance to intervene if you’re monitoring.
The art of steering
When you need to redirect an agent, be specific. Explain why you’re redirecting and how you want it to proceed.
Bad steering: “This doesn’t look right.”
Good steering: “Don’t modify database.js—that file is shared across services. Instead, add the connection pool configuration in api/config/db-pool.js. This keeps the change isolated to the API layer.”
Timing matters. Catch a problem five minutes in, and you might save an hour of ineffective work. Don’t wait until the agent finishes to provide feedback.
You can also stop an agent mid-task and give it refined instructions. Restarting with better direction is simple and often faster than letting a misaligned agent continue.
Why session logs matter
Session logs show reasoning, not just actions. They reveal misunderstandings before they become pull requests, and they improve your future prompts and orchestration practices. When Copilot says “I’m going to refactor the entire authentication system,” that’s your cue to steer.
Tips for the review phase
When your agents finish, you’ll have pull requests to review. Here’s how to do it efficiently. Ensure you review:
Session logs: Understand what the agent did and why. Look for reasoning errors before they become merged code. Did the agent misinterpret your intent? Did it assume something incorrectly?
Files changed: Review the actual code changes. Focus on:
Files you didn’t expect to see modified
Changes that touch shared, risky, or critical code paths
Patterns that don’t match your team’s standards/practices
Missing edge case handling
Checks: Verify that tests pass (your unit tests, Playwright, CI/CD, etc.). When checks fail, don’t just restart the agent. Investigate why. A failing test might reveal the agent misunderstood requirements, not just wrote buggy code.
This pattern gives you the full picture: intent, implementation, and validation.
Ask Copilot to review its own work
After an agent completes a task, ask it:
“What edge cases am I missing?”
“What test coverage is incomplete?”
“How should I fix this failing test?”
Copilot can often identify gaps in its own work, saving you time and improving the final result. Treat it like a junior developer who’s willing to explain their reasoning.
Batch similar reviews
Generating code with agents is straightforward. Reviewing that code—ensuring it meets your standards, does what you want, and that it can be maintained by your team—still requires human judgment.
Improve your review process by grouping similar work together. Review all API changes in one session. Review all documentation changes in another. Your brain context-switches less, and you’ll spot patterns and inconsistencies more easily.
What’s changed for the better
Mission control moves you from babysitting single agent runs to orchestrating a small fleet. You define clear, scoped tasks. You supply just enough context. You launch several agents. The speed gain is not that each task finishes faster; it’s that you unblock more work in the same timeframe.
What makes this possible is discipline: specific prompts, not vague requests. Custom agents in agents.md that carry your patterns so you don’t repeat yourself. Early steering when session logs show drift. Treating logs as reasoning artifacts you mine to write a sharper next prompt. And batching reviews so your brain stays in one mental model long enough to spot subtle inconsistencies. Lead your own team of agents to create something great!
Meet A Few Student Founders Who Turned Ideas into Impact
Imagine Cup alumni have gone on to raise funding, win global recognition, transform industries, and create products that improve everyday lives. Here are just a few of the teams that started exactly where you are:
Opaque Media (Australia)
What began as a dementia care project became a breakthrough simulation tool that was used by NASA to train astronauts for the cognitive challenges of space. Student vision → worldwide application.
This team built an AI-powered prosthetic arm that learns, adapts, and adjusts grip strength in real time. They’ve since earned the GoodSpark Grant and are nearing FDA approval, making advanced prosthetics more accessible for people who need them most.
An AI platform built to narrate the world in real time for people with visual impairments. Trained on 15M+ visuals with 98% accuracy, it’s empowering users with more independence through cutting-edge computer vision.
What started as an IoT project is now a funded agritech company. ProTag raised $1M NZD to scale its cattle-monitoring device, giving farmers the data they need to improve animal health and operations.
Hollo created an AI-driven mental health platform supporting youth communities, earning $1.8M HKD in grants and proving that social impact and smart technology can grow together.
These founders didn’t wait for permission. They built, tested, improved, and Imagine Cup helped them accelerate what was already taking shape.
Good for Business. Good for the World. Built by Students.
The most transformative solutions aren’t always created in corporate labs, they’re often built by students who see the world differently.
Imagine Cup equips student founders with:
Enterprise-grade Microsoft AI
Up to $5,000 in Azure credits
Feedback from industry experts
A global network of innovators
A platform designed to help real startups grow
Every year, we watch student-built solutions turn into companies with impact. Yours could be next.
Posted by Don Turner - Developer Relations Engineer
Jetpack Navigation 3 is now stable, and using it can help you reduce tech debt, provide better separation of concerns, speed up feature development time, and support new form factors. We're dedicating a whole week to providing content to help you learn about Nav3, and start integrating it into your app.
You’ll learn about the library in detail, how to modularize your navigation code, and lots of code recipes for common use cases. At the end of the week, tune into the "Ask Me Anything" session so you can have the experts answer anything you like about Nav3. Here's the full schedule:
Monday: API Overview
Dec 1st, 2025
Learn the most important Nav3 APIs including NavDisplay, NavEntry, and entryProvider with a coding walkthrough video.
Tuesday: Animations
Dec 2nd, 2025
Make your screen transitions look beautiful! Learn how to set custom animations for all screens in your app, and how to override transitions for individual screens that need different behavior.
Wednesday: Deep links
Dec 3rd, 2025
Deep links support has been one of the most requested features from developers. You'll learn how to create deep links with a variety of different code recipes.
Thursday: Modularization
Dec 4th, 2025
Learn how to modularize your navigation code. Avoid circular dependencies by separating navigation keys into their own modules, and learn how to use dependency injection and extension functions to move content into feature modules.
Friday: Ask Me Anything
Dec 5th, 2025
Do you have burning questions? We have a panel of experts waiting to provide answers live at 9am PST on Friday. Ask your questions using the #AskAndroid tag on BlueSky, LinkedIn and X.
Slack’s Security Engineering team is responsible for protecting Slack’s core infrastructure and services. Our security event ingestion pipeline handles billions of events per day from a diverse array of data sources. Reviewing alerts produced by our security detection system is our primary responsibility during on-call shifts.
We’re going to show you how we’re using AI agents to optimize our working efficiency and strengthen Slack’s security defenses. This post is the first in a series that will unpack some of the design choices we’ve made and the many things we’ve learnt along the way.
The Development Process
The Prototype
At the end of May 2025 we had a rudimentary prototype of what would grow into our service. Initially, the service was not much more than a 300 word prompt.
The prompt consisted of five sections:
Orientation: “You are a security analyst that investigates security alerts […]”
Manifest: “You have access to the following data sources: […]”
Methodology: “Your investigation should follow these steps: […] ”
Formatting: “Produce a markdown report of the investigation: […]”
Classification: “Choose a response classification from: […]”
We implemented a simple “stdio” mode MCP server to safely expose a subset of our data sources through the tool call interface. We repurposed a coding agent CLI as an execution environment for our prototype.
The performance of our prototype implementation was highly variable: sometimes it would produce excellent, insightful results with an impressive ability to cross-reference evidence across different data sources. However, sometimes it would quickly jump to a convenient or spurious conclusion without adequately questioning its own methods. For the tool to be useful, we needed consistent performance. We needed greater control over the investigation process.
We spent some time trying to refine our prompt, stressing the need to question assumptions, to verify data from multiple sources, and to make use of the complete set of data sources. While we did have some success with this approach, ultimately prompts are just guidelines; they’re not an effective method for achieving fine-grained control.
The Solution
Our solution was to break down the complex investigation process we’d described in the prompt of our prototype into a sequence of model invocations, each with a single, well-defined purpose and output structure. These simple tasks are chained together by our application.
Each task was given a structured output format. Structured output is a feature that can be used to restrict a model to using a specific output format defined by a JSON schema. The schema is applied to the last output from the model invocation. Using structured outputs isn’t “free”; if the output format is too complicated for the model, the execution can fail. Structured outputs are also subject to the usual problems of cheating and hallucination.
In our initial prototype, we included guidance to “question your evidence”, but had mixed success. With our structured output approach, that guidance had become a separate task in our investigation flow with much more predictable behavior.
This approach gave us more precise control at each step of the investigation process.
From Prototype to Production
While reviewing the literature, two papers particularly influenced our thinking:
These papers describe prompting techniques that introduce multiple personas in the context of a single model invocation. The idea of modelling the investigation using defined personas was intriguing, but in order to maintain control we needed to represent our personas as independent model invocations. Security tabletop exercises, and how we might adapt their conventions to our application, were also a major source of inspiration during the design process.
Our chosen design is built around a team of personas (agents) and the tasks they can perform in the investigation process. Each agent/task pair is modelled with a carefully defined structured output, and our application orchestrates the model invocations, propagating just the right context at each stage.
Investigation Loop
The Director agent poses a question and domain expert agents respond, generating findings. The Critic agent reviews findings for quality and assembles a timeline using the most credible. The Director uses the high-quality findings and timeline to determine how to progress the investigation.
Our design has three defined persona categories:
Director Agent
The Investigation Director. The Director’s responsibility is to progress the investigation from start to finish. The Director interrogates the experts by forming a question, or set of questions, which become the expert’s prompt. The Director uses a journaling tool for planning and organizing the investigation as it progresses.
Expert Agent
A domain expert. Each domain expert has a unique set of domain knowledge and data sources. The experts’ responsibility is to produce findings from their data sources in response to the Director’s questions.
We currently have four experts in our team:
Access: Authentication, authorization and perimeter services.
Cloud: Infrastructure, compute, orchestration, and networking.
Code: Analysis of source code and configuration management.
Threat: Threat analysis and intelligence data sources.
Critic Agent
The Critic is a “meta-expert”. The Critic’s responsibility is to assess and quantify the quality of findings made by domain experts using a rubric we’ve defined. The Critic annotates the experts’ findings with its own analysis and a credibility score for each finding. The Critic’s conclusions are passed back to the Director, closing the loop. The weakly adversarial relationship between the Critic and the expert group helps to mitigate against hallucinations and variability in the interpretation of evidence.
Because each agent/task pair is a separate model invocation we can vary all of the inputs, including the model version, output format, prompts, instructions, and tools. One of many ways we’re using this capability is to create a “knowledge pyramid”.
Knowledge Pyramid
At the bottom of the knowledge pyramid, domain experts generate investigation findings by interrogating complex data sources, requiring many tool calls. Analyzing the returned data can be very token-intensive. Next, the Critic’s review identifies the most interesting findings from that set. During the review process the Critic inspects the experts’ claims and the tool calls and tool results used to support them, which also incurs a significant token overhead. Once the Critic has completed its review, it assembles an up to date investigation timeline, integrating the running investigation timeline and newly gathered findings into a coherent narrative. The condensed timeline, consisting only of the most credible findings, is then passed back to the Director. This design allows us to strategically use low, medium, and high-cost models for the expert, critic, and director functions, respectively.
Investigation Flow
The investigation process is broken into several phases. Phases allow us to vary the structure of the investigation loop as the investigation proceeds. At the moment, we have three phases, but it is simple to add more. The Director persona is responsible for advancing the phase.
Investigations begin in the discovery phase. After each round of investigation the Director decides whether to remain in the current phase or to progress to a new phase.
Discovery
The first phase of each investigation. The goal in the discovery phase is to ensure that every available data source is examined. The Director reviews the state of the investigation and generates a question that is broadcast to the entire expert team.
Director Decision
A “meta-phase” in which the Director decides whether to advance to the next investigation phase or continue in the current one. The task’s prompt includes advice on when to advance to each phase.
Trace
Once the discovery phase has made clear which experts are able to produce relevant findings, the Director transitions the investigation to the trace phase. In the trace phase, the Director chooses a specific expert to question. We also have the flexibility to vary the model invocation parameters by phase, allowing us to use a different model or enhanced token budget.
Conclude
The Director transitions the investigation to the concluding phase when sufficient information has been gathered to produce the final report.
Service Architecture
Our prototype used a coding agent CLI as an execution harness, but that wasn’t suitable for a practical implementation. We needed an interface that would let us observe investigations occurring in realtime, view and share past investigations, and launch ad-hoc investigations. Critically, we needed a way of integrating the system into our existing stack, allowing investigations to be triggered by our existing detection tools. The service architecture we created does all of these things and is quite simple.
Hub
The hub provides the service API and an interface to persistent storage. Besides the usual CRUD-like API, the hub also provides a metrics endpoint so we can visualise system activity, token usage, and manage cost.
Worker
Investigation workers pick up queued investigation tasks from the API. Investigations produce an event stream which is streamed back to the hub through the API. Workers can be scaled to increase throughput as needed.
Dashboard
The Dashboard is used by staff to interact with the service. Running investigations can be observed in real-time, consuming the event stream from the hub. Additionally the dashboard provides management tools, letting us view the details of each model invocation. This capability is invaluable when debugging the system.
Example Report
We’ve included an edited investigation report which demonstrates the potential of the agents to exhibit novel emergent behavior. In this case, the original alert was raised for a specific command sequence, which we analyze because it can be an indicator of compromise. In the course of investigating the alert, the agents independently discovered a separate credential exposure elsewhere in the process ancestry.
The highlighted leaf process triggered the investigation, but the agents traced the process hierarchy and discovered a different issue in an ancestor process.
The text below is a lightly edited version of the report summary from this investigation.
Investigation Report: Credential Exposure in Monitoring Workflow [ESCALATE]
Summary: While investigating [command sequence], the investigation uncovered a credential exposure elsewhere in the process ancestry chain.
Analysis
The investigation confirmed that the command execution on [TIMESTAMP] was part of a legitimate monitoring workflow using [diagnostic tool]. The process ancestry shows the expected execution chain. However, critical security concerns were identified:
Credential Exposure: A credential was exposed in process command line parameters within the ancestry chain, creating significant security risk.
Expert-Critic Contradiction: The expert incorrectly assessed credential handling as secure while the critic correctly identified exposed credentials, indicating analysis blind spots that require attention.
What is notable about this result is that the expert did not raise the credential exposure in its findings; the Critic noticed it as part of its meta-analysis of the expert’s work. The Director then chose to pivot the investigation to focus on this issue instead. In the report, the Director highlights both the need to mitigate the security issue, and to follow-up on the expert’s failure to properly identify the risk. We referred the credential exposure to the service owning team to resolve.
Conclusion
We’re still at an early phase of our journey to streamline security investigations using AI agents, but we’re starting to see meaningful benefits. Our web-based dashboard allows us to launch and watch investigations in real time, and investigations yield interactive, verifiable reports that show how evidence was collected, interpreted, and judged. During our on-call shifts, we’re switching to supervising investigation teams, rather than doing the laborious work of gathering evidence. Unlike static detection rules, our agents often make spontaneous and unprompted discoveries, as we demonstrated in our example report. We’ve seen this occur many times, from highlighting weakness in IAM policies, to identifying problematic code and more.
There’s a great deal more to say. We look forward to sharing more details of how our system works in future blog posts. As a preview of some future content from the series:
Maintaining alignment and orientation during multi-persona investigations
Using artifacts as a communication channel between investigation participants
Human in the loop: human / agent collaboration in security investigations
Acknowledgements
We wanted to give a shout out to all the people that have contributed to this journey:
Chris Smith
Abhi Rathod
Dave Russell
Nate Reeves
Interested in taking on interesting projects, making people’s work lives easier, or just building some pretty cool forms? We’re hiring!
Log in
.png)
