In practice, an agentic AI’s “mind” is structured by these patterns. For example, a well-designed agent might alternate between thinking and acting in a loop to incrementally solve problems (a pattern known as ReAct), or it might plan out a sequence of steps in advance before execution (plan-and-execute pattern). Many advanced agents even combine multiple patterns – for instance, an AI coding assistant may first plan a solution, then reflect on its code and debug it, while a search engine agent might use a ReAct loop within a larger multi-agent workflow. By understanding these patterns and when to use them, developers can create AI agents that are more robust and easier to maintain.

Agentic AI design patterns can be grouped into two broad categories:

• Conceptual (Behavioral) Patterns: High-level reasoning strategies that dictate how the agent thinks, decides, and learns. These patterns define the agent’s cognitive workflow – how it plans tasks, uses tools, or self-corrects errors. They are often inspired by research but have been adopted in industry to make agents more capable and trustworthy.

• Architectural (Code-Level) Patterns: Structural and implementation patterns that organize the agent system. These include how to orchestrate one or many agents, how to manage the agent’s memory/state, and how to integrate tools and external resources. They address the engineering side of building maintainable, scalable agent systems.

Below, we discuss the key design patterns in each category, with descriptions and real-world examples. A summary table for each category is provided to encapsulate the patterns, their purpose, and example implementations.

Conceptual Design Patterns (Reasoning & Behavior)

Conceptual patterns describe how an AI agent reasons through problems and decides on actions. Rather than leaving the LLM to figure everything out unprompted, these patterns impose a structured approach to reasoning – which in turn leads to more reliable and interpretable behavior. Modern LLM-based agents often use one or several of these patterns:

ReAct (Reason + Act) Pattern

Description – ReAct is a foundational reasoning pattern where an agent interleaves thought and action in a loop. At each step, the agent thinks (generates a reasoning trace to decide what to do), then acts (executes an action such as calling a tool or API), then observes the result, and repeats this cycle. This iterative Thought → Action → Observation loop continues until the task is solved or an answer is produced. By explicitly reasoning at each step and using the environment’s feedback, the ReAct pattern helps ground the agent’s decisions in actual observations, reducing hallucination and error rates compared to one-shot answers. ReAct was introduced by researchers in 2022, but quickly proved its practical value and is now a go-to pattern for building tool-using AI agents.

Industry Use – ReAct’s step-by-step approach is well-suited for open-ended tasks that require multiple reasoning steps or external information. It has become the default in many agent frameworks and products. For example, LangChain’s standard agent is built on the ReAct loop – the LLM decides at each step which tool to use (search engines, calculators, databases, etc.), executes it, and uses the tool’s output to guide the next thought. Early web-connected QA systems like WebGPT (OpenAI) followed a ReAct-like process of thinking and searching in turns. Likewise, the popular open-source AutoGPT project uses an inner loop of reasoning and tool calls to iteratively move towards a goal (e.g., continually analyzing its progress and deciding the next action such as web browsing or code execution). ReAct remains popular because it’s simple yet powerful – as a Wollen Labs analysis notes, it’s often an ideal default when you need an LLM to use tools or handle multi-step queries without having to pre-plan the entire solution.

Self-Reflection (Critique & Refinement) Pattern

Description – In the self-reflection pattern, an agent is designed to critically evaluate its own outputs and refine them. Instead of delivering its first answer without question, the agent first generates a solution, then shifts into a “critic” mode to inspect that result, looking for errors, validity issues, or ways to improve the answer. If it identifies a problem, the agent goes back and adjusts its reasoning or tries an alternate approach, effectively performing a self-guided “second draft.” This may repeat for several iterations until the agent is satisfied or an iteration limit is reached. Reflection mitigates the tendency of LLMs to commit to an answer too quickly – by introducing a pause for self-critique, the agent can catch mistakes (factual inaccuracies, unsatisfied constraints, buggy code, etc.) before presenting a final output. This pattern is especially useful in scenarios where accuracy and reliability are more important than speed, allowing the agent to correct itself much like a human reviewing their work.

Industry Use – Many practical AI agents employ reflection to boost quality. For instance, AI coding assistants use self-refinement to reduce errors: an agent can draft code, run a test or review on it, then notice a bug or a failed test and fix its code accordingly. The AI might even generate unit tests for its own code to validate correctness. Anthropic’s Claude, in particular, has been noted to use a form of this pattern – the Claude Code assistant can internally “red team” (self-check) its code for vulnerabilities like SQL injection and correct them, essentially acting as its own first reviewer. In the realm of text generation, content creation bots do something similar by producing an initial draft, then evaluating it against style guidelines or factual references and revising problematic sections. The Reflection pattern (also dubbed “Reflexion” in some literature when it involves learning from past mistakes across multiple attempts) was highlighted by Microsoft researchers as a key to self-correcting agents, and is increasingly common in industry for any task where the cost of a mistake is high.

Planning (Plan-and-Execute) Pattern

Description – The Planning pattern, often implemented as Plan-and-Execute, has an agent formulate a structured plan of action before diving into execution. In this approach, the agent uses its reasoning abilities in a dedicated planning phase to break a complex goal into sub-tasks or steps, creating a high-level game plan. Only once the plan (for example, a list of steps) is ready does the agent enter an execution phase, carrying out each step in sequence (and possibly re-planning if something unexpected occurs). This two-phase approach forces the agent to think ahead about the overall solution path, which can prevent myopic actions and provide a clear direction for complex tasks. Planning is particularly useful when tackling long-horizon tasks with multiple dependencies, because it helps the agent maintain focus on the end goal and systematically work through sub-goals. Compared to the reactive ReAct loop, planning incurs an upfront cost (one or more planning prompts) but can be more efficient for well-structured problems, since the agent doesn’t need to rethink its strategy from scratch at every step.

Industry Use – Many multi-step AI workflows now use plan-and-execute variants. For example, Microsoft’s HuggingGPT (2023) acted as a planner that would interpret a user’s request and generate a plan to invoke various AI models in sequence (for tasks like “create a video from a prompt”). The open-source project BabyAGI similarly maintains a dynamic task list: it creates new tasks and reprioritizes them as it works, which is effectively a continuous planning loop. In the realm of software engineering automation, GPT-Engineer and MetaGPT (2023–2024) both leveraged explicit planning: GPT-Engineer generates a project “spec” and plan before writing code, and MetaGPT assigns different “roles” (like Architect, Coder, Tester – each an agent) to handle complex coding projects collaboratively according to a plan. Planning is a natural fit for any domain where the solution can be outlined as a series of steps – e.g. business workflow automation, where an agent might plan steps like “gather client requirements → run analysis A → generate report → send email with results” before executing them. Many advanced agents actually combine Planning with the Reflection pattern: first plan the approach, then use a self-critique loop to verify each step’s outcome and adjust the plan if necessary.

Tool Use (Tool-Integration) Pattern

Description – The Tool Use pattern enables an AI agent to extend its capabilities by interacting with external tools and services as part of its reasoning process. In practice, the agent is provided with a set of tool interfaces (for example: web search, calculators, databases, code execution, custom APIs) that it can call via specially formatted outputs. At each decision point, the agent can choose to invoke a tool, supply it with input, and then use the tool’s output to inform subsequent reasoning. This pattern is what gives many agentic AIs access to up-to-date information and real-world actions beyond their trained knowledge. Tool use is often combined with the ReAct loop (Thought→Action→Observation) – in fact, the name “ReAct” itself highlights reasoning coupled with actions, and “actions” usually mean tool calls. The key design aspect of this pattern is defining the tools and their usage format clearly to the agent (often in its system prompt) so the agent knows when and how to call them. Proper tool integration can dramatically improve an agent’s effectiveness by allowing it to fetch data, execute code, or delegate subtasks that the LLM can’t handle alone.

Industry Use – Integrating tools with LLM agents is now standard practice. OpenAI’s ChatGPT Plugins and function calling API (2023) are prime examples of the tool use pattern: they let the LLM decide to call functions (tools) like web browsers, calculators, or booking systems by outputting a JSON snippet, which the host system executes. This capability allows ChatGPT-based agents to, for instance, look up current stock prices, retrieve documents, or control home automation devices on behalf of the user. LangChain, a library popular among developers for building AI agents, provides a large collection of tools (Google search, Python interpreter, database connectors, etc.) and frameworks like AgentExecutor to simplify tool calls. Developers specify a tool’s interface (description, input/output format), and the agent’s LLM chooses when to use those tools to answer user requests. Another example is Microsoft’s Jarvis (HuggingGPT), which coordinated calls to various machine-learning models (for image generation, speech recognition, etc.) as tools, all directed by a central LLM planner. In summary, the Tool Use pattern is what transforms an LLM from a static chatbot into a dynamic agent that can interact with software and the world.

Multi-Agent Collaboration (Delegation) Pattern

Description – The Multi-Agent pattern (also called delegation or cooperative agents) involves multiple agents working together on different aspects of a problem, often under the guidance of a coordinator agent. Rather than a single AI handling everything, each agent can be specialized – for example, one might be a Planner agent, another a Research agent, another a Critic or Executor, etc. The agents communicate and pass tasks among themselves, forming an autonomous team of AIs somewhat analogous to a human team with distinct roles. One common architecture is a hierarchical delegation: a manager agent decomposes the goal into sub-tasks and assigns them to worker agents, then integrates their results. Another approach is a decentralized collaboration (sometimes likened to a “swarm” of agents) where multiple agents interact and refine ideas without a single leader, though this can be harder to control. The benefit of multi-agent collaboration is scalability and specialization – complex tasks can be split into manageable pieces, and each sub-agent can use specialized prompts, tools, or even different model types best suited for its subtask. However, coordinating multiple agents adds overhead and complexity (for example, deciding how they communicate, preventing infinite back-and-forth, and merging results).

Industry Use – Multi-agent systems are actively used in industry whenever tasks are too complex for a single agent or require diverse skills. For instance, Perplexity AI’s production search assistant is reported to use a form of multi-agent orchestration: one agent focuses on searching and retrieving relevant information, then passes it to another agent that formulates a coherent answer, with a final agent verifying facts – all orchestrated by a top-level LLM controller. In software development, the open-source MetaGPT project spawns several GPT-4 agents with different roles (Project Manager, Architect, Coder, Tester) to collaboratively build software – exemplifying how delegation can mirror a real-world team. Likewise, HuggingGPT used a central GPT-4 to delegate tasks to specialist AI models (for vision, speech, etc.), effectively creating a multi-agent tool-using system for complex multimodal queries. Even where only one LLM agent is present, it might internally simulate multiple “personas” or reasoning threads that debate or collaborate (an approach used in some chatbot implementations). Multi-agent patterns are powerful, but due to their complexity, many teams will start with a single-agent system and introduce additional agents only as needed for scalability.

Human-in-the-Loop Oversight (Hybrid Human/AI Pattern)

Description – Ensuring human oversight is a design pattern often employed when absolute reliability or safety is required. In a human-in-the-loop pattern, an AI agent may handle a task autonomously up to a point, but will pause at a checkpoint and request human input or approval before proceeding or finalizing its output. This can be implemented by inserting explicit approval steps in the agent’s plan (for example, “If transaction amount > $1000, ask a human for review” or “Before publishing content, get editor approval”). The human-in-the-loop pattern reduces risk by having a person correct the agent’s mistakes or make judgment calls on ambiguities. The downside is that it reduces automation and speed, so it’s typically reserved for cases where errors are costly or where ethical and legal constraints demand a human decision (e.g. medical diagnosis, financial investments, content moderation).

Industry Use – Many real-world “autonomous” systems quietly incorporate human oversight. Customer support bots often escalate to a human representative if they detect certain triggers (like frustration, or a request beyond their authority). Document processing agents that draft responses or contracts might require a human manager’s sign-off before any sensitive communication is sent out. In software development, an AI code-generation agent could be configured to always seek human approval before merging code changes into a production repository. Regulators and industry best practices in areas like healthcare, finance, and law often mandate human review of AI decisions, so designing an agent with built-in human-in-the-loop checkpoints is a common pattern to ensure compliance. For example, an AI medical diagnostic agent may provide a recommendation but a doctor must approve the final diagnosis, or an AI content generator on a news site might prepare an article draft that stays in a queue until an editor reviews and approves it. This pattern is not about improving the AI’s capabilities per se, but about integrating AI into real-world workflows responsibly by combining strengths of AI (speed, scale) with human judgment.

Table 1 below summarizes the Conceptual (Reasoning) Patterns and highlights example implementations:

Table 1 – Conceptual Design Patterns for Agentic AI (Reasoning & Behavior)

Architectural & Code-Level Patterns (Implementation & Orchestration)

While conceptual patterns govern how the AI agent thinks, architectural patterns cover how the overall system is structured and executed in code. These patterns address questions like: should you use one agent or many? How do you organize a sequence of LLM calls and tool invocations? How does the agent remember information between steps? Here we outline key architectural design patterns for agentic AI, along with examples of their usage:

Single-Agent vs. Multi-Agent Architecture

A fundamental decision is whether to build a single-agent system or a multi-agent system. In a single-agent architecture, one LLM (plus its tools) handles the entire task within a single, continuous reasoning loop. This is simpler to implement and debug, since all logic is in one place. Most current AI agents are single-agent by default, and they can already handle many complex tasks by using tools and patterns like ReAct or planning within one agent’s context. A multi-agent architecture uses several LLM agents (or LLMs paired with tools) working in concert, typically with a top-level orchestrator to coordinate them. Multi-agent systems shine for very complex or interdisciplinary problems where different sub-agents can tackle different subtasks or where parallelism is needed. However, they introduce extra complexity in communication and state sharing. Industry experience shows it’s wise to “start simple” with one agent, and only move to a multi-agent design if a single agent is hitting limitations. For example, if you find one agent is struggling to handle all required tools or has to juggle very different skills, that might be a sign to split responsibilities among multiple specialized agents.

Orchestration Patterns (Workflow Structuring)

If your agent’s task involves multiple steps or multiple agents, how do we coordinate the process? Orchestration patterns describe common ways to structure the flow of an agent or multi-agent system. Several patterns are prevalent:

• Deterministic Sequence (Pipeline): A fixed, linear sequence of operations or model calls, where each step’s output feeds into the next. This is essentially a hard-coded workflow, not dynamic decision-making by the agent. It’s suitable for well-defined processes (for example: retrieve data → summarize → format output) that never veer off script. Industry example: Many Retrieval-Augmented Generation (RAG) systems for Q\&A use a simple pipeline: first retrieve documents, then pass them with the query to an LLM for answering. Pipelines are easy to audit and fast, but not flexible with changing requirements or unexpected inputs.

• Dynamic Loop (Iterative Refinement): A loop where an agent (or a pair of agents in a generator-critic duo) repeats a cycle of steps until a condition is met. This could be an internal loop within a single agent (like the ReAct reasoning loop or a self-refinement loop that continues until a solution is validated), or a loop between multiple agents (e.g. one agent proposes an answer, another evaluates it, and they iterate). Industry example: Automated software debugging can be done with an iterative loop: an AI writes code, tests it, then debugs based on failures, repeating until tests pass. Similarly, a planning agent might continually update a task list as new goals emerge (as in BabyAGI’s task loop). Looping patterns are powerful for allowing continuous improvement and adaptability, but developers must implement safeguards (like max iterations or timeouts) to prevent infinite loops.

• Parallel Branching (Concurrent Tasks): An orchestration where multiple sub-tasks or agents run in parallel, and their results are combined at the end. This is useful for speeding up tasks by exploiting parallelism or obtaining multiple perspectives at once. Industry example: A complex business intelligence agent might fork into parallel branches – one agent analyzes sales data, another monitors social media trends – and then a final process merges insights into a single report. Another example is using an ensemble of agents to independently research a question and then aggregating their answers to increase accuracy. Parallel orchestration can reduce overall latency, but requires a way to merge or reconcile outputs and can consume more resources.

• Hierarchical Delegation: A multi-agent orchestration where a central “manager” agent dynamically delegates tasks to one or more worker agents and coordinates the results. This is essentially a runtime planner-executor system: the manager interprets the user’s request, breaks it into pieces, then might even spawn new agents (or call different services) to handle each piece. After each subtask, the manager evaluates results and may assign new tasks or adjust the plan. Industry example: HuggingGPT had GPT-4 as a top-level controller that would create subtasks and call various AI models (as tools) to address each part, then synthesize an answer. Similarly, some AI assistants use a manager agent that decides when to ask a knowledge-base Q\&A agent versus when to consult a calculator or when to request human help. The benefit is extreme flexibility – the workflow is decided on-the-fly by the AI – but the challenge is that the prompt for the manager agent must clearly define how to make these decisions, and debugging such systems can be difficult.

• Decentralized Cooperation (Swarm): An advanced pattern where multiple agents freely communicate and collaborate without a single point of control. For example, agents might message each other, ask each other questions, and vote on answers. This is analogous to a team meeting where ideas are discussed and refined among peers. While mostly experimental, companies have explored using swarms of agents to generate creative ideas or to do complex analyses by consensus. Example: In 2023, Google’s DeepMind described using multiple agents debating each other’s answers to improve factual accuracy (the “society of minds” approach). Swarm orchestration can yield rich results, but it’s the most complex to implement and prone to chatter or deadlocks if not carefully constrained. In practice, this is less common in industry compared to the manager/worker model.

Memory Management Pattern

LLM-based agents don’t have persistent memory of past interactions unless we provide it. The memory management pattern is about how an agent stores and retrieves information over time to maintain context across long tasks. In practical terms, agent memory is often divided into short-term memory (the information in the LLM’s active context window, which is limited) and long-term memory (information saved to an external store that can be fetched when needed). Common approaches include:

• Summarization Buffer: The agent keeps a rolling summary of earlier conversation turns or task progress and prepends that summary in the prompt when the raw history gets too long. This condenses past context to fit the context window.

• Vector Database Memory: Key facts, prior results, or entire documents can be embedded into high-dimensional vectors and stored in a vector database. When needed, the agent finds relevant items by semantic similarity search and injects them into context. For example, an agent might store everything it learns about a project in a Pinecone or Weaviate vector store; later, when a new question arises, it retrieves the most relevant pieces of that stored knowledge to inform its answer.

• Knowledge Base & Retrieval-Augmented Generation (RAG): This is a variant of the tool-use pattern: the agent has access to a document retrieval system (like ElasticSearch or a corporate wiki) and can ask it for information. In effect, the agent’s “memory” is an external knowledge base that it queries as needed. This ensures the agent’s knowledge stays up-to-date without retraining the model. Many enterprise agents use RAG as a memory mechanism – for instance, a customer service agent might retrieve a customer’s profile and past tickets from a database when the customer asks a question.

• Persistent Storage & State Files: Some agents write intermediate results or state to files or databases during their operation. This can include writing a draft output to a file, logging completed sub-tasks, or noting progress. Persisting state allows the agent to be paused and resumed, or to recover from errors without starting over. In software automation, an agent might maintain a “to-do list” file on disk that it updates as it completes tasks (as in certain AutoGPT variants). As one industry guide noted, even using simple files can be an effective first approach to agent memory, leveraging the fact that LLMs have been trained on reading/writing files and code. Over time, teams may migrate to databases for more robust concurrent access and query capabilities as their agent’s memory grows or needs to be shared.

Efficient memory management is crucial for long-running agents – it prevents the LLM from “forgetting” important details and avoids overloading the context with irrelevant data. Many frameworks (like LangChain or LlamaIndex) provide memory components to handle summaries or vector-based retrieval. For instance, default AutoGPT setups in 2023 used a Pinecone vector database for long-term memory, enabling the agent to remember facts across runs (though newer versions explored local file-based memory as well). By 2025, numerous vendors (including Oracle and others) have published guidelines on choosing memory architectures (comparing vectors vs. graphs vs. relational DBs) to help developers design scalable agent memory. The consensus is to start simple (even plain files or JSON logs for single-user agents) and only move to complex memory stores when needed.

Error Handling and Safety Guardrails

Autonomous agents must be constructed with robust error handling and safety mechanisms to be viable in production. This is less a single pattern and more a set of best practices that should be baked into an agent’s design:

• Retry and Fallback Logic: Agents often call external tools and APIs, which can fail or return unexpected results. A well-designed agent catches errors (e.g., tool exceptions or timeouts) and implements fallback strategies. For example, if a web search query fails, the agent could try a backup search API, or if an API returns an error, the agent can reformat the query and retry a limited number of times before giving up. This prevents the entire agent from crashing due to one failed step.

• Iteration Limits & Timeouts: To avoid infinite loops (a risk whenever an agent reasons in a loop or multiple agents call each other), developers set bounds – e.g., maximum iterations or a watchdog timer to stop the agent after a certain duration. In practice, AutoGPT and similar systems implemented user-defined limits on how many cycles the agent could go through before pausing for user confirmation. These controls ensure the agent doesn’t run amok consuming resources or getting stuck chasing a wrong objective.

• Validation and Policy Enforcement: Many production systems add explicit guardrail checks on the agent’s outputs. This could be as simple as validating the format of an answer (e.g., ensure a JSON output is valid JSON) or as complex as running a content filter on the agent’s response to filter out any policy violations (hate speech, privacy leaks, etc.). In tool-using agents, it’s also common to sandbox dangerous actions – for instance, an agent allowed to execute Python code might run in a restricted environment, and certain sensitive operations (file deletion, external network calls) might be disallowed or require special authorization. Such guardrails are critical when deploying agents in enterprise settings, preventing costly mistakes and ensuring compliance with regulations.

In summary, code-level patterns ensure that an agent’s implementation is organized and resilient. For instance, a single-agent ReAct loop might be embedded in a larger deterministic workflow with human-in-the-loop oversight and robust error-handling – combining predictability with flexibility. The table below summarizes the main architectural patterns and practices:

Table 2 – Architectural Design Patterns & Practices for Agentic AI

Conclusion & Best Practices

Design patterns provide a toolbox for building effective agentic AI systems. Rather than coding each agent from scratch, developers can leverage these proven patterns – or even use libraries (like LangChain or AgentPatterns library which offers several ready-made agent patterns) – to bootstrap their agent development. When choosing patterns for your project, consider the problem complexity and requirements:

• Start Simple, Then Add Complexity: It’s usually best to begin with the simplest approach that could work. For example, if a single prompt with retrieval (a deterministic RAG chain) answers your question, you may not need a full agent. If you do need an agent, a single-agent ReAct with a few tools is a good starting point for many use cases. Only introduce additional patterns (like planning or multiple agents) when the simpler setup fails to produce satisfactory results or can’t handle the scope of the task. Unnecessary complexity can make agents harder to debug and slower.

• Match Patterns to Problems: Different tasks call for different strategies. If the task involves open exploration or uncertainty, a ReAct-style or even a Tree-of-Thoughts approach might be appropriate. If the task is well-structured and lengthy, a Planning (plan-and-execute) pattern could work best. For tasks requiring high accuracy, consider adding Reflection so the agent can self-correct. For tasks that span multiple domains or skill sets, a Multi-agent delegation pattern may be effective. Refer back to the pattern tables above for “best for” guidance (and notice how many implementations actually use several patterns together).

• Combine Patterns for Synergy: In practice, many robust agent systems mix and match patterns rather than relying on just one. For instance, an agent may use a Planning phase to outline a solution, then enter a ReAct loop to execute each step, and finally invoke a Reflection loop to verify the result. Or you might have a mostly sequential pipeline with a single “agent step” in the middle that uses a ReAct loop to handle a particularly unpredictable part of the process. Don’t hesitate to compose patterns as needed – but do so in a controlled way (for example, ensure that if you have multiple agents or loops, you have timeouts or iteration limits to keep things on track).

• Maintain Oversight and Iterate: No matter which patterns you use, remember that autonomous agents require careful monitoring and refinement. Log the agent’s decisions and tool uses, and if possible, have it explain its chain-of-thought (or use a “transparency” pattern like ReAct that produces an explicit reasoning trace). This makes it easier to debug when the agent gets confused. Incorporate human-in-the-loop steps for critical junctures where a mistake would be costly. Test your agent thoroughly with diverse scenarios, and be prepared to adjust its prompts or add new tools/patterns if it encounters failure modes. As Anthropic’s engineers note, building an effective agent is an iterative process – use telemetry and feedback to continually improve the agent’s reasoning strategies and safety over time.

By understanding and applying these design patterns, AI developers can create agents that are not only smarter, but also more reliable and easier to maintain. The landscape of agentic AI is rapidly evolving, but these patterns have emerged as fundamental building blocks for current industry implementations. Whether it’s a virtual assistant automating business workflows or a conversational agent conducting research, a solid grasp of agent design patterns will help ensure your AI acts intelligently and safely in pursuit of its goals.

References

Building Effective AI Agents \ Anthropic

anthropic.com

Agent system design patterns | Databricks on AWS

docs.databricks.com

Wollen Labs

wollenlabs.com

ReAct Agent Pattern — Agent Patterns 0.2.0 documentation

agent-patterns.readthedocs.io

Agentic Reasoning Patterns: 5 Powerful Frameworks for Smarter AI Agents

servicesground.com

Inside Claude Code: how Anthropic rethought coding with agents

mlopscommunity.substack.com

Agent Patterns Documentation — Agent Patterns 0.2.0 documentation

agent-patterns.readthedocs.io

Comparing File Systems and Databases for Effective AI Agent Memory Management | developers

blogs.oracle.com

Prompt chaining (sometimes called the Pipeline pattern) is a powerful strategy for handling complex tasks with large language models (LLMs). Instead of relying on a single, monolithic prompt, prompt chaining breaks down a problem into a sequence of smaller, focused steps. Each step is addressed individually, and the output from one prompt is passed as input to the next. This modular approach improves reliability, makes debugging easier, and enables integration with external tools and APIs.

Why Prompt Chaining?

• Reduces cognitive load: Each step is simpler and less ambiguous, lowering the chance of errors and hallucinations.

• Improves reliability: Sequential decomposition allows for validation and correction at each stage.

• Enables tool integration: Each step can interact with external systems, APIs, or databases.

• Foundation for agentic systems: Enables multi-step reasoning, planning, and decision-making.

Pattern Example (Three Steps)

1. Summarize raw material with tight instructions.

2. Extract structured data (JSON) from the summary.

3. Compose human-ready content using the structured output.

Assigning a distinct role to each step (e.g., Market Analyst, Trend Analyst, Documentation Writer) helps focus the model and improves output quality.

C# Code Sample: Agent Framework Sequential Chain

Prerequisites

• .NET 8+

• Azure OpenAI resource & deployed model (e.g., gpt-4o-mini)

• Sign in with az login or use an API key credential

• NuGet packages (preview):

    dotnet add package Azure.AI.OpenAI --prerelease
    dotnet add package Azure.Identity
    dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
  

using System;
using System.Text.Json;
using Azure.Identity;
using Azure.AI.OpenAI;
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.OpenAI;

class Program
{
    static async System.Threading.Tasks.Task Main()
    {
        var endpoint = new Uri("https://<your-azure-openai>.openai.azure.com/");
        var modelId = "<your-deployment-or-model-id>"; // e.g., gpt-4o-mini
        var client = new AzureOpenAIClient(endpoint, new AzureCliCredential());

        // General-purpose agent; constrain behavior per step via instructions
        AIAgent agent = client
            .GetChatClient(modelId)
            .CreateAIAgent(instructions:
                "You are a disciplined assistant. Follow the user's step-specific instructions exactly.");

        // Step 1: Summarize
        var source = @"The new laptop model features a 3.5 GHz octa-core CPU, 16GB RAM, and a 1TB NVMe SSD.
                       It targets power users, claims 12-hour battery life, and includes Wi-Fi 7.";

        string summary = await agent.RunAsync(
            "ROLE: Market Analyst.\n" +
            "TASK: Summarize the key findings in <=120 words. Stay factual and concise.\n" +
            "TEXT:\n" + source);

        if (string.IsNullOrWhiteSpace(summary))
            throw new InvalidOperationException("Step 1 produced an empty summary.");

        // Step 2: Extract trends as structured JSON
        string trendsRaw = await agent.RunAsync(
            "ROLE: Trend Analyst.\n" +
            "TASK: Return ONLY strict JSON. Extract 3 trends with 'name' and 'supportingData'.\n" +
            "SCHEMA: { \"trends\": [{\"name\": string, \"supportingData\": string}] }\n" +
            "INPUT:\n" + summary);

        JsonDocument trendsDoc;
        try
        {
            trendsDoc = JsonDocument.Parse(trendsRaw);
            _ = trendsDoc.RootElement.GetProperty("trends");
        }
        catch (Exception ex)
        {
            // Corrective re-prompt
            trendsRaw = await agent.RunAsync(
                "The previous output was not valid JSON per schema.\n" +
                "Return ONLY strict JSON with shape:\n" +
                "{ \"trends\": [{\"name\": string, \"supportingData\": string}] }\n" +
                "INPUT:\n" + summary);
            trendsDoc = JsonDocument.Parse(trendsRaw);
        }

        var trendsJson = trendsDoc.RootElement.GetProperty("trends").ToString();

        // Step 3: Compose email
        string email = await agent.RunAsync(
            "ROLE: Expert Documentation Writer.\n" +
            "TASK: Draft a concise email (<=150 words) to the marketing team.\n" +
            "Include: short intro, bullet list with trend names + supporting data, single CTA line.\n" +
            "CONTEXT:\n" +
            $"Summary:\n{summary}\n" +
            $"Trends (JSON):\n{trendsJson}");

        Console.WriteLine("\n--- Summary ---\n" + summary);
        Console.WriteLine("\n--- Trends (JSON) ---\n" + trendsRaw);
        Console.WriteLine("\n--- Email ---\n" + email);
    }
}

Moedim.Edgar steps directly into that gap. It’s a modern C#/.NET library—and a companion MCP server—that turns raw EDGAR APIs into type-safe, async-friendly building blocks for AI agents and financial applications.

In other words: this repo (https://github.com/kdcllc/Moedim.Edgar) is about turning SEC filings into AI-ready context.

From Legacy Feeds to AI-Native Infrastructure

At its core, [Moedim.Edgar](https://github.com/kdcllc/Moedim.Edgar) is a .NET 8 library that wraps the SEC EDGAR APIs with:

• A modern IHttpClientFactory-based HTTP client

• Strongly-typed C# models for EDGAR data structures

• Full async/await support

• Dependency injection extensions via Microsoft.Extensions.DependencyInjection

• Configurable options via a clean options pattern

The goal is not just “yet another HTTP wrapper,” but a library that feels native in contemporary .NET backends and can be dropped into real systems: microservices, data pipelines, and—most interestingly—AI assistants.

The project structure reflects that intent:

• Moedim.Edgar – the core EDGAR client: services, models, query types.

• Moedim.Edgar.Sample – a comprehensive sample app walking through all main services.

• Moedim.Edgar.Mcp – an MCP server that exposes EDGAR as tools for AI agents.

That last project is where things shift from “API client” to “AI infrastructure.”

Why EDGAR Matters for AI

If you’re building AI for:

• Equity research

• Corporate credit analysis

• Competitive intel

• Regulatory/compliance workflows

…you quickly realize you need structured, reliable access to:

• Company facts (revenues, assets, liabilities, etc.)

• Specific financial concepts over time

• Filings history and search by form types (10-K, 10-Q, 8-K, etc.)

• Latest filings for monitoring and alerts

• Filing-level details and document structures

Moedim.Edgar’s models and services map almost exactly onto this mental model:

• Company Lookup – resolve companies to CIKs and metadata.

• Company Facts – explore the full universe of reported facts.

• Company Concept – zoom in on a specific metric (e.g. revenue).

• Edgar Search – discovery of filings with flexible queries.

• Latest Filings – what just hit the tape.

• Filing Details – drill into specific submissions.

The sample application ships as a guided tour: configuration, service usage, pagination, error handling, and output examples. It’s less a “hello world” and more a “here’s how you’d actually wire this into a research workflow.”

MCP: Giving AI Agents First-Class Access to EDGAR

The most forward-looking part of the repo is Moedim.Edgar.Mcp, an implementation of a Model Context Protocol server that exposes EDGAR as a toolset to AI assistants.

Instead of having your AI agent hallucinate SEC data or rely on brittle scraping, you define tools that:

• Look up companies

• Pull company facts

• Fetch concept-specific timeseries

• Search filings

• Retrieve filing details

The MCP server is built on:

• The ModelContextProtocol C# SDK

• The Moedim.Edgar library itself

• The .NET Generic Host (Microsoft.Extensions.Hosting)

The documentation calls out:

• Self-contained binaries for Windows, macOS, and Linux (no runtime required).

• Targeting .NET 10 SDK for development, but compiled into cross-platform, self-contained applications.

• A structured TOOLS.md describing 13 tools grouped by domain:

  • Company data tools

  • Filing search tools

  • Filing details tools

  • Configuration and usage examples

  • Common financial concepts and SEC forms

This is exactly the kind of pattern we’re seeing emerge across AI ecosystems: instead of “prompting the model to Google things,” you grant the model a well-documented, typed interface to critical data systems, and let it reason on top.

Moedim.Edgar.Mcp is that interface for EDGAR.

Design Choices That Matter to AI Builders

Several technical choices in this repo are particularly relevant if you’re building AI-infused systems:

1. Type-Safe Financial Models

   By encoding EDGAR concepts in strongly-typed C# models, you get:

   • Safer transformations into embeddings, feature vectors, or RAG documents.

   • Less room for silent shape mismatches when serializing/deserializing data for AI pipelines.

   • Clearer documentation and discoverable APIs directly from IDE tooling.

2. Async-First API Surface

   Fetching EDGAR data is inherently I/O-bound and often pagination-heavy. Full async support throughout means:

   • You can build high-throughput ingestion services.

   • Agents can concurrently fetch multiple companies or filings without blocking threads.

   • You’re well-positioned to scale in cloud-native environments.

3. Dependency Injection as a First-Class Citizen

   Support for Microsoft.Extensions.DependencyInjection makes the EDGAR client feel like any other infrastructure dependency:

   • Register the client and services once.

   • Inject into orchestrators, background workers, or tool handlers.

   • Swap or wrap services for testing or extended logic.

This is especially key when bridging between a host (e.g., an MCP server or orchestration engine) and the low-level EDGAR API.

4. Configuration via Options

   SecEdgarOptions centralizes configuration—user agent, rate limiting behavior, base URLs, etc.—so that:

   • You can tune behavior per environment.

   • You can plug in secrets/configuration providers for regulated deployments.

   • You can adapt when the SEC inevitably adjusts its API boundaries.

A Path to AI-Native Financial Research

Taken together, Moedim.Edgar and Moedim.Edgar.Mcp offer a compelling blueprint for turning a legacy data source into something AI-native:

1. Normalize the data source with a robust, typed client library.

2. Provide a guided sample that demonstrates real-world usage patterns and edge cases.

3. Expose an AI-friendly protocol layer (MCP) that lets assistants call into that library safely and reliably.

4. Ship cross-platform binaries so teams can run the AI data services anywhere—locally, in containers, or on hosted environments.

This is a pattern that can be replicated for:

• Other regulators (e.g., ESMA, FCA, local securities commissions)

• Alternative data sources (shipping, satellite, ESG, credit)

• Internal enterprise systems (ERP, CRM, risk engines)

Moedim.Edgar just happens to tackle one of the most foundational public datasets in finance.

Why This Matters Now

As LLM-based copilots move from “answering questions” to powering workflows, they need deep, structured, and reliable access to domain data. For financial workflows, EDGAR is table stakes.

Projects like Moedim.Edgar show how you can:

• Respect the underlying API and its constraints.

• Wrap it in a developer-friendly, cloud-native .NET library.

• Then layer on an AI-native protocol (MCP) that lets assistants plug directly into the data without brittle scraping or ad-hoc glue code.

If you’re building AI systems that touch public companies, this repo is less a “nice utility” and more a reference architecture for how to turn a legacy data source into a first-class AI tool.

And if nothing else, it’s a reminder that sometimes the most impactful AI work isn’t in training bigger models—it’s in making the right data reliably available to the models we already have.

This post explains why teams choose Moedim.Mapper, how it differs from AutoMapper, and provides a step‑by‑step migration walkthrough (including examples and migration tooling tips) so you can move confidently.

Repository: https://github.com/kdcllc/Moedim.Mapper

TL;DR

• Moedim.Mapper focuses on explicit, clear mapping code that’s easy to reason about and debug.

• It reduces runtime surprises by favoring compile‑time safety and more direct code generation patterns.

• The project includes migration tooling that helps convert AutoMapper Profiles into Moedim mapping code scaffolds.

• This post gives quick before/after examples and a migration checklist so you can plan the transition.

Why migrate? Pain points with AutoMapper

• Implicit mapping: AutoMapper’s convention-based mapping is convenient but can hide logic. When mappings come from conventions or profiles spread across the codebase, diagnosing unexpected values becomes harder.

• Runtime surprises: Missing mappings or configuration mistakes often result in runtime behavior that can be subtle to track down.

• Debugging: Tracing mapping logic in generated expression trees is difficult for many developers.

• Performance: Depending on usage patterns, reflection and expression trees can add overhead (especially for high-throughput scenarios).

What Moedim.Mapper brings

• Explicit mapping definitions that are readable and easy to debug.

• A smaller mental model — mappings are explicit code rather than implicit conventions.

• Tooling to help convert existing AutoMapper Profiles into Moedim mapping code.

• Better productivity for teams that prefer to keep mapping logic visible and testable alongside the rest of the code.

Quick comparison (conceptual)

• AutoMapper: Convention + Profiles -> runtime expression tree / reflection mapping

• Moedim.Mapper: Explicit definitions (and/or source-generated code) -> direct, readable mapping code

Quickstart — examples

1. Example AutoMapper Profile (before)

using AutoMapper;

public class CustomerProfile : Profile
{
    public CustomerProfile()
    {
        CreateMap<CustomerEntity, CustomerDto>()
            .ForMember(d => d.FullName, opt => opt.MapFrom(s => s.FirstName + " " + s.LastName))
            .ForMember(d => d.IsActive, opt => opt.MapFrom(s => s.Status == Status.Active));
    }
}

2. Equivalent mapping with Moedim.Mapper (after)

• Moedim.Mapper favors explicit converters/mappers which you can place next to your DTOs or in a dedicated mappings folder:

public class CustomerMapper : IMapper<CustomerEntity, CustomerDto>
{
    public CustomerDto Map(CustomerEntity s)
    {
        if (s == null) return null;
        return new CustomerDto
        {
            Id = s.Id,
            FullName = $"{s.FirstName} {s.LastName}",
            Email = s.Email,
            IsActive = s.Status == Status.Active
        };
    }
}

3. Registering mappings with DI

• With AutoMapper you typically add profiles:

services.AddAutoMapper(typeof(CustomerProfile).Assembly);

• With Moedim.Mapper, registration is explicit and usually just registering mappers or allowing convention-based scanning:

services.AddScoped<IMapper<CustomerEntity, CustomerDto>, CustomerMapper>();
// or if Moedim provides helper scanning:
services.AddMoedimMappers(typeof(CustomerMapper).Assembly);

Migration tool — make the move faster One reason teams delay migration is the perceived cost of rewriting all mapping profiles. To help, Moedim.Mapper includes migration tooling in the repository that:

• Scans AutoMapper Profile classes (and/or scans compiled assemblies)

• Generates scaffolded mapping classes that follow Moedim.Mapper patterns

• Preserves custom MapFrom expressions as inline assignments when possible

• Emits TODO comments when conversion is ambiguous so you can inspect and finalize migration

Example (high level) CLI usage

• Scan your project and emit scaffolded mappers to a folder (the exact CLI and arguments are in the repository's tools folder; adjust to what your checkout provides):

# hypothetical example — check the repo for exact CLI usage
dotnet tool run moedim-migrator --source ./MyProject --out ./GeneratedMappers

What the migrator does for the earlier example

• Converts CreateMap/ForMember MapFrom expressions into explicit assignments.

• For complex expressions that use external methods or value resolvers, the migrator emits equivalent inline code or a TODO to implement a helper.

After running the migrator you'll get a set of ready-to-review mapping classes you can include in your project and refine.

Step-by-step migration plan

1. Add Moedim.Mapper to your solution

   • Install from NuGet (example):

       dotnet add package Moedim.Mapper
     

2. Run the migration tool against the assembly that contains your AutoMapper profiles

   • Review generated files in GeneratedMappers (or whichever output folder you chose)

3. Add the generated mappers to your project and compile

   • Fix any TODOs the migrator emitted (these are places where manual attention is required)

4. Register mappers in DI (either manually or using a provided scanning helper)

5. Run your unit tests to verify behavior

6. Remove AutoMapper package and profiles once everything is validated

Practical tips and patterns

• Migrate incrementally: Start with a bounded area (e.g., a feature or microservice). Migrate only the mappings touched by that feature.

• Keep tests: If you have unit or integration tests that validate mapping output, keep them in place — they will provide quick feedback that the migration preserved behavior.

• Use the generated scaffolds as a starting point — hand-tune complex mappings to be idiomatic and efficient.

• Embrace explicitness: Where AutoMapper used magic and conventions, Moedim.Mapper asks you to be intentional. This pays off in maintainability.

Advanced scenarios

• Collection mappings: Most mappers need to handle IEnumerable -> List etc. Moedim.Mapper provides helpers (or simple loops) for these conversions. The migration tooling will scaffold collection conversions when it detects them.

• Projection and IQueryable: If you relied on AutoMapper’s ProjectTo for EF Core projections, check Moedim.Mapper documentation for pattern alternatives (explicit projections or expression-based projections) and migrate gradually.

• Conditional mapping: Translate AutoMapper Condition/PreCondition to explicit guards in the mapping method.

Testing and verification

• Keep your mapping tests. For each migrated mapping, add a unit test that creates a source object and asserts the target object properties.

• Add test coverage around corner cases (nulls, empty lists, special enums) — the explicit mapping code makes it easier to reason about and test those edge cases.

Performance, debugging, and maintenance

• With explicit mapping code you can step through mapping logic in your debugger easily. This reduces time-to-diagnose when values are wrong.

• The generated mapping code tends to be straightforward and optimized by the runtime; you eliminate hidden expression tree building or reflection at runtime in many cases.

• Explicit mappings are easier to profile and inline small optimizations when they matter.

FAQ Q: Will I lose productivity without AutoMapper’s conventions? A: You will lose some of the automatic "magic", but you gain predictability and explicit control. The migration tooling helps narrow the work by scaffolding the bulk of classes; from there, refining is usually minimal.

Q: Can I keep AutoMapper and Moedim.Mapper side-by-side during migration? A: Yes. Migrate mappings incrementally, and keep both libraries until you’ve validated parity. The migration plan above is designed for incremental transitions.

Q: Does Moedim.Mapper support the same advanced features as AutoMapper (value resolvers, converters, projection)? A: Moedim.Mapper focuses on clear and explicit mapping primitives. For advanced scenarios you typically implement small helper methods or converters; these are explicit and directly testable. Check the repository for guides and examples.

Call to action

• Try the migration on a small feature first. Run the migrator, review the output, and keep tests green.

• Browse the repo: https://github.com/kdcllc/Moedim.Mapper

• If you find missing scenarios or want smoother migration for your codebase patterns, open an issue or contribute a PR — your real-world mappings improve the tooling for everyone.

Closing Migrating from AutoMapper to Moedim.Mapper is about trading some of AutoMapper’s convenience for clearer, debuggable, and maintainable mapping code. With provided migration tooling and a small, sensible plan, you can reduce runtime surprises, simplify debugging, and make mapping logic part of your application's readable, testable codebase.

Happy mapping — and if you'd like, I can:

• generate example migration output for one of your Profile classes,

• produce a checklist specific to your repo structure,

• or draft a PR to integrate generated mappers into your project. Just tell me which Profile (or file path) to convert.

What is CronScheduler.AspNetCore?

CronScheduler.AspNetCore is a library specifically designed for .NET Core applications, whether you’re using IHost or IWebHost. It adheres to the KISS (Keep It Simple, Stupid) principle, making it a straightforward alternative to more complex schedulers.

Key Features

1. Lightweight and Easy-to-Use: Unlike other scheduling libraries, CronScheduler.AspNetCore is designed to be lightweight, ensuring that it doesn’t add unnecessary overhead to your application.

2. Cron Syntax: The library uses cron syntax for scheduling tasks, making it familiar and easy to use for those who have worked with cron jobs before.

3. Async Initialization: With the IStartupJob feature, you can initialize critical processes asynchronously before the host starts, ensuring your application is ready to go even in complex environments like Kubernetes.

4. Flexible Hosting: Whether you’re hosting your application in AspNetCore or using a generic IHost, CronScheduler.AspNetCore has you covered.

Integrating Generative AI

Generative AI, a branch of artificial intelligence capable of creating new content such as text, images, and code, can further enhance the capabilities of CronScheduler.AspNetCore. By leveraging generative AI, you can automate the creation of complex scheduling configurations, generate dynamic task parameters, and even predict optimal scheduling times based on historical data.

Example Use Case: Dynamic Task Generation

Imagine you need to schedule tasks that vary based on user behavior or external data. Generative AI can analyze patterns and generate appropriate cron expressions dynamically. Here’s a conceptual example:

C#

public class DynamicCronJob : ICronJob
{
    private readonly IGenerativeAIService _aiService;

    public DynamicCronJob(IGenerativeAIService aiService)
    {
        _aiService = aiService;
    }

    public async Task ExecuteAsync(CancellationToken cancellationToken)
    {
        var cronExpression = await _aiService.GenerateCronExpressionAsync();
        // Schedule the task based on the generated cron expression
    }
}

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddSingleton<IGenerativeAIService, GenerativeAIService>();
        services.AddCronScheduler(config =>
        {
            config.AddJob<DynamicCronJob>("*/5 * * * * *"); // Initial placeholder
        });
    }
}

In this example, DynamicCronJob uses a generative AI service to create cron expressions dynamically, allowing for more flexible and adaptive scheduling.

Getting Started

To get started with CronScheduler.AspNetCore, you need to install the appropriate package. For AspNetCore hosting, use the following command:

dotnet add package CronScheduler.AspNetCore

For IHost hosting, use:

dotnet add package CronScheduler.Extensions

Conclusion

CronScheduler.AspNetCore is a powerful yet simple tool for managing scheduled tasks in .NET Core applications. Its lightweight nature and ease of use make it an excellent choice for developers looking to streamline their task scheduling processes. By integrating generative AI, you can take your scheduling capabilities to the next level, making your applications more adaptive and intelligent.

Give it a try and simplify your scheduling today!

As a developer, you're always looking for ways to optimize your workflow, reduce costs, and increase productivity. That's where the Azure AI CLI comes in – a powerful tool that enables you to seamlessly integrate Azure AI services into your development process.

In this post, we'll explore the benefits of using the Azure AI CLI and walk you through a simple project setup for Semantic Kernel and Agents.

What is Azure AI CLI?

The Azure AI CLI is a cross-platform command-line tool that allows you to connect and use Azure AI services without writing code. With just a few commands, you can access a wide range of AI capabilities, including natural language processing (NLP), computer vision, and more.

REPO: https://github.com/Azure/azure-ai-cli

Advantages of Using Azure AI CLI

1. Streamlined Workflow: The Azure AI CLI simplifies your development workflow by providing a single interface to all Azure AI services. No more switching between different tools or services – just a few commands to get you started.

2. Increased Productivity: With the Azure AI CLI, you can automate repetitive tasks and focus on higher-level creative work. This means you'll be able to deliver projects faster and with greater accuracy.

3. Cost-Effective: The Azure AI CLI allows you to pay only for what you use, reducing costs and minimizing waste. Plus, you can scale up or down as needed, without worrying about upfront costs.

4. Access to Advanced AI Capabilities: The Azure AI CLI gives you access to a wide range of advanced AI capabilities, including NLP, computer vision, and more. This means you can create more sophisticated projects and applications that truly impress.

Getting Started with the Azure AI CLI

Ready to start using the Azure AI CLI? Here's a simple project setup for Semantic Kernel and Agents:

    # 1. install dotnet core
    # https://dotnet.microsoft.com/en-us/download

    # 2. create manifest file for the project
    dotnet new tool-manifest

    # 3. install azure ai cli
    dotnet tool install Azure.AI.CLI --prerelease

    # 4. init the tooling, this step will cache credentials locally
    dotnet ai init

    # 5. list all templates available
    dotnet ai dev new list

    # 6. create this template 
    dotnet ai dev new sk-chat-with-agents

    # 7. run this template with all of the env vars loaded, thanks to azure ai cli
    dotnet ai dev shell --run "dotnet run"

By following these steps, you'll be able to set up a simple project for Semantic Kernel and Agents using the Azure AI CLI.

The following is the SK Agents at work:

Conclusion

The Azure AI CLI is a powerful tool that can help streamline your development workflow, increase productivity, and reduce costs. With its advanced AI capabilities and simplified interface, it's an essential tool for any developer looking to take their projects to the next level.

In this post, we've explored the benefits of using the Azure AI CLI and walked you through a simple project setup for Semantic Kernel and Agents. Whether you're just starting out or looking to expand your skills, the Azure AI CLI is an excellent choice for anyone interested in developing with AI.

Completed code can be found at: https://github.com/kdcllc/generative-ai

What is CronSchedulerApp?

CronSchedulerApp is a .NET Core web application that demonstrates various scheduled job scenarios using the CronScheduler.AspNetCore library. It includes examples of background tasks, startup jobs, and scheduled jobs that can be used in your own applications.

Benefits of Using Scheduled Jobs

Scheduled jobs offer several benefits for your generative AI application:

• Efficient processing: By scheduling jobs to run at specific times or intervals, you can ensure that computationally intensive tasks are executed during off-peak hours or when system resources are available.

• Improved reliability: Scheduled jobs can be configured to retry failed tasks or execute alternative tasks if the primary job fails.

• Enhanced scalability: Azure Container Apps provide a scalable platform for your application. By scheduling jobs, you can take advantage of this scalability and ensure that your application can handle increased traffic or processing demands.

Getting Started with CronSchedulerApp

To get started with CronSchedulerApp, follow these steps:

1. Install the NuGet package: Install the CronScheduler.AspNetCore NuGet package in your .NET Core project.

2. Configure the scheduler: In your Program.cs , configure the scheduler using the AddScheduler method. This method allows you to add jobs and customize job options, such as the run interval, maximum retries, and error handling.

Example Job: TorahQuoteJob

Let's take a look at an example job, TorahQuoteJob, which retrieves a random verse from the Torah and updates the current verses in the TorahVerses service:

public class TorahQuoteJob : IScheduledJob
{
    private readonly ILogger<TorahQuoteJob> _logger;
    private readonly ITorahVersesService _torahVersesService;

    public TorahQuoteJob(ILogger<TorahQuoteJob> logger, ITorahVersesService torahVersesService)
    {
        _logger = logger;
        _torahVersesService = torahVersesService;
    }

    public string Name { get; } = nameof(TorahQuoteJob);

    public async Task ExecuteAsync(CancellationToken cancellationToken)
    {
        _logger.LogInformation("Executing scheduled job: {jobName}", Name);
        // Retrieve a random verse from the Torah
        var verse = await _torahVersesService.GetRandomVerse();
        // Update the current verses in the `TorahVerses` service
        await _torahVersesService.UpdateCurrentVerses(verse);
        await Task.CompletedTask;
    }
}

Configuring Job Options

You can configure job options using a custom class that inherits from SchedulerOptions. For example:

public class TorahQuoteJobOptions : SchedulerOptions
{
    public string SomeOption { get; set; } = string.Empty;
}

Registering the Job

To register the TorahQuoteJob with the scheduler, use the following code:

builder.Services.AddScheduler(builder =>
{
    builder.Services.AddSingleton<TorahVerses>();
    builder.Services
        .AddHttpClient<TorahService>()
        .AddTransientHttpErrorPolicy(p => p.RetryAsync());

    builder.AddJob<TorahQuoteJob, TorahQuoteJobOptions>();
    builder.Services.AddScoped<UserService>();
    builder.AddJob<UserJob, UserJobOptions>();

    builder.AddUnobservedTaskExceptionHandler(sp =>
    {
        var logger = sp.GetRequiredService<ILoggerFactory>().CreateLogger("CronJobs");
        return (sender, args) =>
        {
            logger?.LogError(args.Exception?.Message);
            args.SetObserved();
        };
    });
});

Running the Application

To run your application with scheduled jobs, follow these steps:

1. Build and deploy: Build and deploy your .NET Core project to Azure Container Apps.

2. Configure the scheduler: Configure the scheduler using the AddScheduler method in your Program.cs .

3. Run the application: Run your application to execute scheduled jobs based on their configured schedules.

In this blog post, we've explored how to use CronScheduler.AspNetCore library with CronSchedulerApp to schedule generative AI jobs inside Azure Container Apps. By leveraging scheduled jobs, you can improve the efficiency, reliability, and scalability of your application.

Happy coding..

Today, we'll take it to the next level by deploying RavenDB Accelerator to Azure Container Apps using azd up. This accelerator is designed specifically for Proof of Concept (POC) projects, making it easy to set up a RavenDB-backed ASP.NET Core application and deploy it to Azure.

Prerequisites

Before we dive into the deployment process, make sure you have the following prerequisites:

• .NET SDK 8.0

• Docker

• Azure CLI

• Azure Developer CLI (azd)

Deploying using azd up

To deploy the RavenDB Accelerator to Azure Container Apps, follow these steps:

1. Install Azure Developer CLI:

   Download and install azd cli (Azure Developer CLI) from the official documentation.

2. Clone the repo:

    git clone https://github.com/kdcllc/ravendb-donet-accelerator.git
   

3. Run azd up:

   Navigate to the root directory of your project and run the command:

    azd up
   

4. Follow the steps:

   Follow the prompts to create Azure resources, such as a resource group, log analytics workspace, application insights, container registry, key vault, storage account, and container apps environment.

Post deployment steps to secure RavenDb

After deploying the accelerator, navigate to the Ingress section of ravendb Azure Container App in the Azure Container Environment. You'll need to:

1. Select -> 'Allow traffic from IPs configured below, deny all other traffic'

2. Click -> 'Add the app's outbound IP address'

3. Add any other IP addresses you want to have access to RavenDb.

Conclusion

In this post, we demonstrated how to deploy RavenDB Accelerator to Azure Container Apps using azd up. This accelerator is designed for Proof of Concept (POC) projects and provides a complete solution for building and deploying ASP.NET Core applications with RavenDB. By following these steps, you can quickly set up a robust database solution for your generative AI project.

Whether you're working on a chatbot that can generate human-like responses or an image generator that can create stunning artwork, RavenDB provides the foundation you need to bring your vision to life. So why wait? Get started with RavenDB today and unlock the full potential of your generative AI project!

In this blog post, we'll explore why RavenDB is the best option for new generative AI projects. We'll delve into the unique features of RavenDB that make it an ideal choice for building and deploying these innovative applications.

Why a NoSQL Database?

Before diving into the specifics of RavenDB, let's first consider why a NoSQL database is essential for generative AI projects. Unlike traditional relational databases, NoSQL databases are designed to handle large amounts of unstructured or semi-structured data. This flexibility is crucial for generative AI applications, which often rely on vast amounts of text, images, and other forms of unstructured data.

RavenDB: A Perfect Fit for Generative AI

So, why RavenDB specifically? Here are a few compelling reasons:

1. JSON Document-Oriented Database: RavenDB is built around JSON documents, making it an ideal fit for handling the complex data structures required by generative AI applications.

2. Schema-Less: Unlike traditional databases, RavenDB doesn't require a predefined schema. This allows developers to add new fields or modify existing ones without having to worry about complex schema updates.

3. High-Performance: RavenDB is designed for high-performance and scalability, making it an excellent choice for large-scale generative AI projects that require fast data processing and retrieval.

4. ACID Compliance: RavenDB ensures ACID compliance, guaranteeing that database transactions are processed reliably and securely.

Why RavenDB Beats the Competition

While there are other NoSQL databases available, RavenDB stands out from the competition in several key areas:

1. Ease of Use: RavenDB has a relatively low barrier to entry, making it easier for developers to get started with their generative AI projects.

2. Flexibility: RavenDB's flexible data model allows developers to adapt their database schema as their project evolves.

3. Scalability: RavenDB is designed for scalability, ensuring that your generative AI application can handle increasing amounts of data and user traffic.

Conclusion

As the field of generative AI continues to expand, having a reliable and scalable database like RavenDB is crucial for building and deploying innovative applications. With its JSON document-oriented design, schema-less approach, high-performance capabilities, and ACID compliance, RavenDB is the perfect choice for new generative AI projects.

Whether you're working on a chatbot that can generate human-like responses or an image generator that can create stunning artwork, RavenDB provides the foundation you need to bring your vision to life. So why wait? Get started with RavenDB today and unlock the full potential of your generative AI project!