# When Agents Hire Their Own Team: Inside Hypermode's Concierge

Ryan Fox-Tyler, Hypermode | Agents in Production 2025 | 22:50

Source: https://www.youtube.com/watch?v=shtlcu7otiw
Channel: MLOps Community, now AAIF Live (https://www.youtube.com/@AAIFLive-x1r). Summarised by MLOps Talks.
Page: https://mlopstalks.com/talks/when-agents-hire-their-own-team-inside-hypermodes-concierge
Published: 2025-08-13
Tags: agents, memory, multi-agent

## TL;DR
- Concierge lets people create agents through natural-language conversation, then teaches those agents repeatable tasks from real work.
- An actor-based runtime gives dynamically created agents isolated contexts, concurrency, recovery, event-driven execution, and persistent state.
- Ryan Fox-Tyler argues that teams should spend less time hand-defining agents and more time training and evaluating them with subject-matter experts.

## Summary
Ryan Fox-Tyler explains how Hypermode built Concierge, an agent that creates other agents. The system starts with a short natural-language description, gathers missing context, connects tools, and turns successful interactions into repeatable tasks. He compares this process with teaching an intern, where the goal is to correct one attempt and capture the procedure rather than write every instruction in advance. He then describes two patterns for dynamic agent creation: spawning isolated agent instances for parts of a problem and using a conductor agent to assemble a team with different contexts and models. Hypermode runs these agents on an actor-based runtime designed for concurrency, failure isolation, event-driven work, persistence, and passivation. In the question period, Ryan discusses keeping memory layers separate so organisations can choose how agents share and review context. His central operational point is that low-cost experimentation and a simple production path need to exist together.

## Key ideas
### Natural-language conversations can replace much of the manual agent setup
[00:40](https://www.youtube.com/watch?v=shtlcu7otiw&t=40s)
Ryan Fox-Tyler uses the peanut butter and jelly exercise to explain why people struggle to specify every step on a blank page. A conversation makes the missing steps easier to surface. Hypermode applies that idea to agent construction. The intended loop is to define an agent's scope, connect its tools, train it on concrete work, and let it improve through use. Ryan says teams spend too much time hand-building the first stages. Concierge moves more of that work into natural language, so a user can describe an outcome and answer questions while the system fills in the details.

### Concierge creates an agent by collecting context and testing the result
[02:48](https://www.youtube.com/watch?v=shtlcu7otiw&t=168s)
In the demonstration, Ryan asks Concierge to create a product marketer for Hypermode without writing a detailed system prompt. The system asks for the company website, researches Hypermode, and uses that information to create an agent called Launchpark. It writes the system instructions, lets Ryan choose a model, and connects sources such as GitHub and product documentation. Ryan then chats with the new agent to inspect its available tools. The example shows Concierge handling definition and connection through a short exchange instead of requiring Ryan to configure every field himself.

### Training an agent means turning a successful interaction into a repeatable task
[05:56](https://www.youtube.com/watch?v=shtlcu7otiw&t=356s)
Ryan teaches Launchpark to update a website headline and open a pull request. The agent initially searches too broadly and becomes confused, so Ryan gives it more precise repository instructions. After the agent finds the file, creates a branch, changes the headline, and opens the pull request, Ryan selects 'create task'. Concierge converts the steps and corrections into a repeatable prompt. Ryan distinguishes this from training a model. The agent is learning a standard operating procedure, much as a person learns how to perform a job after being corrected once.

### Dynamic agent instances can divide work while keeping contexts separate
[09:18](https://www.youtube.com/watch?v=shtlcu7otiw&t=558s)
Ryan describes a fraud-detection system that can create separate agent instances for different parts of an investigation. One instance might examine one dimension of fraud, another might inspect a second dimension, and another might track resolution time against service objectives. Keeping those contexts separate helps limit scale problems and lets the work run in parallel. The agents can report back to a larger process without forcing every step into one growing conversation. Ryan presents this as a natural use of agents that are created for a task rather than as permanent identities.

### A conductor agent can assemble a team with different roles and models
[10:09](https://www.youtube.com/watch?v=shtlcu7otiw&t=609s)
A second pattern is a conductor that creates an agent team for a larger job. Ryan gives a blog post as an example. One agent could write, another could edit, and another could handle image generation, with each working in a separate context. The team can also use different models for different jobs. Ryan says separating the contexts reduces confusion and bias from the original message. The conductor then brings the outputs back together. This extends Concierge's basic ability to create one agent into a system that creates temporary specialists on demand.

### An actor-based runtime gives large numbers of agents operational boundaries
[11:11](https://www.youtube.com/watch?v=shtlcu7otiw&t=671s)
Hypermode uses an actor-based runtime to manage agents as isolated computational units with defined interfaces. Ryan names concurrency, failure isolation and recovery, event-driven execution, and clustered persistence as important properties. The system needs to handle agents that respond to chats, schedules, or events, including tasks that continue asynchronously. A failure in one agent should not affect others. State also needs to survive infrastructure changes, since cloud machines can be replaced. The runtime absorbs these infrastructure concerns instead of making every agent implementation handle them separately.

### Passivation lets idle agents release resources without losing their state
[14:15](https://www.youtube.com/watch?v=shtlcu7otiw&t=855s)
Ryan focuses on passivation, where an actor that is not doing work releases resources back to the cluster. He argues that chat looks synchronous but contains many short asynchronous events separated by idle periods. Keeping every agent running all the time would waste compute. With passivation, an agent can scale down between requests and resume with its thread state when work returns. Ryan describes this as getting serverless resource use without restarting from zero or retrieving all state from a slower external store. The approach is intended for systems with thousands or hundreds of thousands of agents.

### Subject-matter experts should train agents while platform teams provide the infrastructure
[15:44](https://www.youtube.com/watch?v=shtlcu7otiw&t=944s)
Ryan says the person who has studied fraud for 15 or 20 years should teach a fraud agent how to make decisions. A data scientist should focus on supplying the right data and understanding emerging practices. He compares this division of work with MLOps, where a platform enables specialists to run experiments and make domain decisions. In his view, teams should keep definition and connection lightweight, then spend more effort on training and self-learning. That shift matters because the useful difference between agents will come from their context and procedures, not from weeks spent plumbing together each agent.

### Production systems need controlled memory boundaries
[18:33](https://www.youtube.com/watch?v=shtlcu7otiw&t=1113s)
In the question period, Ryan separates real-time state from short-term and long-term memory. If every actor continuously writes into shared short-term memory, behaviour becomes harder to predict, which is a problem for large and regulated organisations. Some teams may let agents write to long-term context through APIs and messages. Others may send proposed memories to an offline store, review them, run evaluations, and publish approved changes. Ryan also mentions the risk of users trying to pollute or attack a shared memory. Separate layers let each organisation choose how much sharing and review it needs.

## Notable quotes
- "We fundamentally believe that this should all happen in natural language, right? And that is why we built Concierge with this ability to actually create another agent through an agent." (02:29)
- "The real fun part though is when I hit this create task button, what it's going to do is going to take everything it's learned, take all those steps and turn that into a repeatable prompt." (08:32)
- "If we really optimize the cost to experiment to be near zero and the path to production is simple. Both have to be true." (17:03)
- "I think it's really important that you have clear segregations within your architecture so you can make distinct choices of how you want to plug that system together." (21:43)

## Tools & references mentioned
- Hypermode
- Concierge
- Astronomer
- Google Calendar
- GitHub
- GPT-4.1
- Gemini
- Anthropic
- Modus
- Dgraph
- MLOps
- actor model

## Who should watch
- You are building agent products and need a practical way to let users create workflows without writing every system instruction by hand.
- Your team is deciding how to run many asynchronous agents with isolation, persistence, and controlled resource use.
- You are responsible for agent evaluation or memory governance in a regulated setting and want to separate live state from reviewed long-term context.

## Related talks

- [AI Agents: The Future of Productivity, or Just a Fad?](https://mlopstalks.com/talks/ai-agents-the-future-of-productivity-or-just-a-fad) (Sam Partee, Arcade AI, 35:18)
- [The Agent Landscape - Lessons Learned Putting Agents Into Production](https://mlopstalks.com/talks/the-agent-landscape-lessons-learned-putting-agents-into-production) (Paul van der Boor & Floris Fok, Prosus Group, 1:08:41)
- [Too much lock-in for too little gain: agent frameworks are a dead-end](https://mlopstalks.com/talks/too-much-lock-in-for-too-little-gain-agent-frameworks-are-a-dead-end) (Valliappa Lakshmanan, 35:37)
- [Sub-Agent Architectures: What You Can Leverage](https://mlopstalks.com/talks/sub-agent-architectures-what-you-can-leverage) (Sidd Seethepalli, Vellum, 14:48)
- [The Future of Compute: How AI Agents Are Reshaping Infrastructure](https://mlopstalks.com/talks/the-future-of-compute-how-ai-agents-are-reshaping-infrastructure) (Diego Oppenheimer, Guardrails AI, 38:34)