When Agents Hire Their Own Team: Inside Hypermode’s Concierge // Ryan Fox-Tyler

The process of building effective AI agents can be compared to the “peanut butter and jelly challenge,” where instructing someone step-by-step through a conversation is far more effective than writing down a complete set of instructions from a blank slate. Humans excel at incremental teaching, and agent development should mirror this interactive process.

Currently, too much energy is spent on the initial definition and connection phases of agent creation. The focus should instead shift towards the training and self-learning phases, where subject matter experts can interactively teach agents how to perform tasks. This approach accelerates development and uncovers what is truly possible with current technology. To facilitate this, the entire agent creation process should be grounded in natural language.

The Agent Creation and Training Loop

The core development cycle for an agent follows four stages:

1. Define: Setting the agent’s scope and purpose.
2. Connect: Granting the agent access to the necessary tools and data sources.
3. Train: Teaching the agent how to perform specific tasks through interaction and feedback. This is where the most value is created.
4. Self-Learn: Allowing the agent to improve its performance over time based on new interactions and outcomes.

Hypermode’s platform, with its “Concierge” agent, is designed to rapidly move through the “Define” and “Connect” stages, enabling developers and experts to spend more time on “Train.”

In a demonstration, an agent called “Concierge” is tasked with creating a new “product marketer” agent for Hypermode.

• Instead of being given a detailed prompt, Concierge asks clarifying questions to build the new agent’s system prompt, such as what company it represents.
• It then autonomously researches hypermode.com to understand the company’s products and market position.
• Once the new agent, “LaunchSpark,” is created, it can be instantly connected to tools like GitHub and product documentation.
• The user then trains LaunchSpark by walking it through a task: updating a headline on the company website. The process is conversational, with the user providing guidance when the agent gets overwhelmed or confused, much like mentoring an intern.
• After successfully finding the correct file and opening a pull request, the entire interaction is saved as a new, repeatable “task.” This transforms the conversational training session into a standard operating procedure for the agent, codifying the learned process.

Architectural Patterns for Dynamic Agent Systems

The ability to create agents dynamically and at near-zero cost unlocks several powerful architectural patterns:

• Spawning New Agent Instances: For complex problems like fraud detection, a primary agent can spawn multiple, isolated sub-agents. Each sub-agent can investigate a different dimension of the problem in parallel (e.g., one agent investigates transaction history, another checks user data). This approach constrains the context for each agent, improving scalability and allowing for parallelized execution.
• The Conductor Agent: A conductor agent can dynamically assemble a custom team of specialized agents to complete a task. For instance, to create a blog post, a conductor could spin up a writer agent (using a model like Claude 3 Sonnet), an editor agent (using a model like Claude 3 Opus for its strong editing capabilities), and an image-generation agent. This allows for using the best model for each sub-task and keeps the agents’ contexts from biasing one another.

The Technical Foundation: An Actor-Based Runtime

Supporting thousands of dynamically created agents requires a robust and scalable runtime. A simple library-based approach is insufficient. Hypermode is built on an actor-based runtime, a computational model that provides several key benefits for scaling agentic systems.

• Concurrency and Scale: The actor model is inherently concurrent, making it possible to scale to hundreds of thousands of parallel agent instances. This is crucial not just for chat applications but for agents performing asynchronous background tasks triggered by events or schedules.
• Fault Isolation and Recovery: Each agent runs as an isolated actor. If one agent crashes, it does not impact the others. This is a core tenet of building resilient, cloud-native systems.
• Event-Driven Design: The architecture is fundamentally event-driven, which is essential for managing asynchronous task execution, queuing, and handling dependencies in a resilient manner.
• Clustered Persistence: The runtime manages state persistence across the cluster, ensuring high availability for long-running tasks. This abstracts away the complexities of underlying infrastructure failures, such as virtual machines rotating.

A particularly powerful feature of this model is passivation. When an actor (agent) is idle, it releases its resources back to the cluster. Because agent interactions are often a series of small, asynchronous events with significant idle time in between, passivation allows the system to operate with serverless efficiency. An agent can be “woken up” with only a few milliseconds of overhead, as its state is maintained, avoiding the need to re-retrieve all information from a cold start.

The Philosophy: Lowering the Cost of Experimentation

The ultimate goal is to create an environment where the cost to experiment is near zero and the path to production is simple. When these two conditions are met, innovation flourishes. By building on an open-source actor framework (modus) and providing the tools for rapid, conversational agent development, the aim is to empower experts to build, train, and scale the next generation of AI agents.

• Tags:
• Feature
• MLOps
• Agentic Systems
• Actor Model
• Hypermode
• Dynamic Agents
• AI Orchestration