Make it more agentic

Original MAGIC blog post

MAGIC (Machine-Assisted Generative Intelligence and Coordination) is a framework for creating autonomous systems powered by Large Language Models (LLMs). It provides a structured environment where agents, powered by LLMs, perform tasks through defined actions, which can be executed directly or delegated to specialized agents, enhancing the system's flexibility and capability.

The MAGIC framework aims to simplify the process of building and managing complex, LLM-powered automation systems by providing a clear, well-defined structure for agent creation, task delegation, and action execution -- and a long overly-verbose name to avoid any miscommunication.

This repo serves as an example for how to implement these concepts in a very basic way, there isnt anything to install or use other then the CLI. If there is anything useful to you please feel free to copy/paste or use as a reference, whatever. If there is enough interest, I may wrap a few things up into something a bit more structured.

The local examples are stubbed out with fake db and there is a CLI for running a stateful session locally. I like to use bun, but you could use node + npm/pnpm/whatever but will have to run the cli with the direct command using tsnode or something similar.

Install the deps

  bun install

Run cli directly

  bun run cli

Use the magic command

  bun link

  bun link magic

  magic

• Agent Identity and Parameters: Each agent within the MAGIC system has a defined identity and set of parameters guiding its operations, interactions, and decision-making processes.
• Agent Schema: This defines the expected structured output from an agent, ensuring consistency and reliability in the agent's responses and actions.
• Action Definitions: Actions represent tasks or operations an agent can perform. Each action has defined input parameters, a handler function, and context describing its purpose and usage conditions.

1. Context and resource gathering and resolution: The system will gather all relevant context and external resources it needs, given the input parameters - then resolve what of that set will be used to provide to the orchestration agent based on the configuration of the system (max token count, etc..)

2. Task Reception and Analysis: The orchestration agent analyzes incoming context and input parameters to understand their requirements and context.

3. Delegate Selection and Task Execution: Selects appropriate delegate agents or action handlers for task execution, who then process and perform the tasks, leveraging their specialized capabilities.

4. Aggregation and Response: Post-execution, the orchestration agent synthesizes the results, preparing responses or actions in alignment with overarching objectives.

5. Feedback Loop: Continuously reviews outcomes to refine task distribution and execution, enhancing the system’s efficiency and adaptability.

This structured workflow, built around the core components of MAGIC, enables the creation of flexible, adaptable, and efficient LLM-powered automation systems that can handle a wide range of tasks and scenarios.

Actions in MAGIC are defined by their ability to cause change or fetch information as needed. Actions can be classified based on whether they have side effects or contribute to ongoing context awareness and decision-making processes.

• Direct Action Execution: Agents execute actions based on the LLM’s insights and predefined parameters, directly affecting the system or environment.

• Delegated Action Execution: Complex tasks are delegated to specialized agents, known as delegates, which are designed to handle specific operations efficiently. These delegates can be other LLM-powered agents or specialized automation systems, allowing for polymorphic task execution.

• Side Effect and Context-Aware Actions: Actions are categorized based on their nature—producing direct side effects or aiding in ongoing decision-making. This distinction aids in the management of action flows and their impact on the system.

In orchestrated delegation, a primary agent acts as a coordinator, directing tasks to delegate agents based on their specialized capabilities and the task's requirements.

• Orchestration Agent: Manages the distribution of tasks, ensuring they are executed efficiently and effectively by the most suitable delegate.

• Delegate Agents: Perform the actions they are assigned, utilizing their specialized skills and knowledge to achieve the best outcome.

In the ever-evolving quest to anthropomorphize our algorithms, we've recently landed on ‘agentic’ to describe all things AI + automation (except for sometimes) - but.. What is an agent? What does it mean to be agentic? Is it just a bit of MAGIC?

Every person I speak to has a different definition, and it’s hard to take anyone seriously when they attempt to describe something simple with something vague.

In this example and anywhere else in this code, agents are defined as a preconfigured instance of an LLM call, with an “identity” prompt and some optional set of static or dynamic messages pre- or post- pended to every request.

Implementing a system that uses the ideas described in MAGIC is relatively simple - depending on the use case, it can scale up to handle an enormous amount of complexity - but the concepts remain the same at every new layer of added functionality.

You will notice in the examples that I do not rely on llm function calling for the execution of actions - the reason is twofold:

1. I usually want to keep the option to swap out a provider or model that may not support the same function calling ability

2. Anecdotal, but I have used this approach as well as function calling and multi function calling to try and achieve the same results and have observed that in most cases I am better able to prompt my way into having the agent adhere to my rules around when/what for calling functions when I define them in this way. (Behind the scenes - to get the structured response we are using function calling when available - the action and actionParams are just params for our singular function that is requesting the structured response)

It works for me, but do what makes you happy.

In a scenario like automated task management, the MAGIC system could use a core agent to assess the tasks at hand and delegate specific actions to other agents designed to handle those tasks. For example, the core agent might delegate a task like "schedule a meeting with John" to a calendar management agent, which would then handle the specifics of finding an available time slot and sending out the meeting invitation.

In a conversational agent scenario, MAGIC would manage dialogue flow, content generation, and context retention, dynamically adjusting responses and actions based on the conversation's evolution and external data inputs. For instance, if a user asks about a specific product, the core agent could delegate the task of retrieving product information to a specialized product catalog agent, which would then return the relevant details to be incorporated into the core agent's response.

With a clear, well-defined and structured approach to agent creation, task delegation, and action execution, MAGIC demonstrates that the power of simple, thoughtful design and implementation of systems that leverage the capabilities of LLMs to solve real-world problems.

So, as we continue to build agentic systems and ponder the meaning of agency in the context of AI, let’s remember that success of our "agentic" systems will be measured not by the cleverness of their names , but by their ability to make a difference in the lives of the people they serve. So let’s build with that in mind, and let the results speak for themselves.—— If you're interested in experimenting with the MAGIC framework or have ideas for how it could be improved, I encourage you to check out the code and share your thoughts.

At Novy, we are building LLM-powered solutions for clients across a wide range of industries. Our team is constantly learning, experimenting with new techniques, and exploring innovative ideas. MAGIC is based on a high-level architecture we have employed successfully in many projects.

In the future, we may open-source more of the components we use to build our systems, allowing the community to benefit from our experience and contribute to the development of advanced LLM-powered automation solutions.

If you're interested in discussing how these systems can evolve, tools you wish existed, or exploring what's possible with LLM-powered automation, please reach out @dimitrikennedy, I’m always excited to connect share ideas.