DEV Community: rosidotidev

In-Depth Comparison: Workflow Control with LangGraph and CrewAI

rosidotidev — Fri, 01 Aug 2025 15:47:07 +0000

(Originally published on my blog: https://roby73.hashnode.dev/in-depth-comparison-workflow-control-with-langgraph-and-crewai)
Choosing between CrewAI and LangGraph for multi-agent orchestration isn’t trivial, especially for developers balancing rapid prototyping with future scalability.

Personally, I gravitate toward CrewAI for its straightforward setup and developer-friendly abstractions. It lets you build production-ready agent flows in minutes, staying focused on business logic rather than complex orchestration architecture. That ease of use and quick iteration cadence make CrewAI a great fit for many projects.

That said, LangGraph has quickly become the go-to framework for large, stateful projects in production, thanks to its expressive graph-based DSL and wide adoption among major tech players. It offers granular control over state, dependencies, and memory, which is often necessary for complex or long-running workflows.

Absolute Control Over Agent Steps: LangGraph vs. CrewAI

One of LangGraph’s undeniable strengths is the absolute control it offers over every single step executed by agents in the workflow. Thanks to its explicit graph-based architecture, you precisely define nodes, edges, and state transitions. This granular orchestration lets you monitor, intervene, and debug the entire flow of execution with full visibility.

In contrast, CrewAI’s abstraction via agents and tasks simplifies setup and speeds development, but sometimes this comes at the cost of less direct visibility and control over internal step execution. The orchestration logic is more implicit and "black-boxed" inside the Crew abstractions, which can make fine-grained intervention more challenging.

That said, with the introduction of Flows in CrewAI—explicitly defined workflows coordinating agents and tasks—you can reclaim a similar level of control and transparency over execution. The Flows feature lets you model sequences, conditions, and branching explicitly, reducing the "black box" effect while still keeping CrewAI’s ease of use.

The Java Verifier examples below provide a clear demonstration of this: while LangGraph exposes every node and edge explicitly, CrewAI Flows allow similarly controlled stepwise execution and monitoring inside a more developer-friendly environment.

Example: The Java Verifier

To illustrate the difference in abstraction and workflow style between CrewAI and LangGraph, here is a minimal “Verifier” agent implementation in both frameworks. The goal of this verifier is to validate, correct, and optimize small Java code snippets. The workflow is designed with a loop: it first checks the code for syntax errors. If an error is found, it attempts to correct the code and then re-enters the verification step. This "verify-correct" loop continues until the code is deemed syntactically correct. Only then does the workflow proceed to the final step of optimizing the code for readability and performance. You can find all the code shown in this post on this Github repo (Java-Verifier-LangGraph-CrewAI)

1. CrewAI: Java Verifier with Flow

(This image has been generated using the functionality at the end of the provided Python code)

CrewAI Flows allow you to define a multi-agent workflow in a class-based structure that feels familiar to developers. You declare agents and then use decorators (@start, @router, @listen) to map out the flow. This structure keeps the logic contained and easy to read. For this particular example, we chose to orchestrate the individual agents directly within the Flow rather than using a complete Crew. This approach gives us more direct control over each agent's step, which was ideal for this straightforward, cyclical process. It's important to note that in more complex scenarios, CrewAI's flexibility allows you to orchestrate entire Crews of agents, leveraging their collective intelligence for a different level of abstraction.

from typing import Any, Dict, List
from dotenv import load_dotenv
from pydantic import BaseModel, Field

from crewai.agent import Agent
from crewai.flow.flow import Flow, listen, start, router

load_dotenv()

class CodeValidationState(BaseModel):
    code: str = ""
    syntax_status: str = ""

class JavaCodeValidationFlow(Flow[CodeValidationState]):

    analyzer_agent = Agent(
        role="Java code syntax analyzer",
        goal="Receive Java code and reply exactly with 'correct' or 'incorrect' based on syntax.",
        backstory="You are a meticulous and precise code quality tool."
    )

    corrector_agent = Agent(
        role="Java code corrector",
        goal="Receive syntactically incorrect Java code and return corrected code with valid syntax only. Return only Java code with no explanation and no markdown",
        backstory="You are an expert Java programmer who fixes code errors.",
        verbose=True
    )

    optimizer_agent = Agent(
        role="Java code optimizer",
        goal="Receive syntactically correct Java code and optimize it for readability and performance without changing logic. Return only Java compilable code with no explanation and no markdown",
        backstory="You are a senior developer specializing in code optimization."
    )

    @start("try_again")
    def start_analysis(self):
        """Starts the workflow, sends the code to the analyzer."""
        print(f"Starting code analysis...\n {self.state.code}")
        result = self.analyzer_agent.kickoff(self.state.code)
        syntax_status = result.raw
        self.state.syntax_status = syntax_status
        print(f"Analyzer result: {syntax_status}")

    @router(start_analysis)
    def conditional_next_step(self):
        """Decides whether to proceed with correction or optimization."""
        syntax_status = self.state.syntax_status
        print(f"conditional_next_step {syntax_status}")
        if syntax_status=="correct":
            return "correct"
        else:
            return "incorrect"

    @router("incorrect")
    def correct_code_step(self):
        """Performs code correction."""
        result = self.corrector_agent.kickoff(self.state.code)
        print(f"Corrector: code corrected.\n {result.raw}")
        self.state.code = result.raw
        return "try_again"

    @listen("correct")
    def optimize_code_step(self):
        """Performs code optimization."""
        result = self.optimizer_agent.kickoff(self.state.code)
        self.state.code = result.raw
        print("Optimizer: optimization finished.")
        print("\nWorkflow complete. Final optimized code:")
        print("---" * 20)
        print(self.state.code)
        print("---" * 20)

# Example usage of the workflow
def run_code_validation_flow():
    # Initial Java code with a syntax error (missing semicolon)
    initial_java_code = """
    public class Test {
        public static void main(String[] args) {
            System.out.println("Hello, World!"
        }
    }
    """
    flow = JavaCodeValidationFlow()

    print("Starting CrewAI Java code validation flow...\n")
    # Start the workflow and get the final result
    flow.kickoff(inputs={"code": initial_java_code})
    return flow

if __name__ == "__main__":
    flow=run_code_validation_flow()
    flow.plot('my_flow_plot')

Mental Model: In CrewAI, you first define the roles and goals of your agents. Then, you use a Flow to orchestrate them through a series of steps. The flow itself feels like a regular class with methods, where decorators handle the routing logic. This keeps the logic contained and aligned with a developer's class-based thinking. Notice that here we are using default LLM used by CrewAI that at the minute is “gpt-4o-mini“.

2. LangGraph: Java Verifier with Graph

(This image has been generated using the functionality at the end of the provided Python code)

LangGraph's approach is more explicit and foundational. You define a graph with nodes and edges, where each node is a function. The state of the workflow is passed explicitly between nodes, and conditional edges are used to manage the flow.

import os
from langgraph.graph import StateGraph, END
from dotenv import load_dotenv
from typing import TypedDict, Annotated  # Import TypedDict and Annotated
from langgraph.types import Command
from langchain_openai import OpenAI
from IPython.display import Image, display
# Ensure your OpenAI API Key is set in environment variable OPENAI_API_KEY
load_dotenv()
# Define your state schema
class CodeState(TypedDict):
    code: str
    is_correct: bool
class JavaVerifierGraph(StateGraph):
    def __init__(self):
        # Initialize LangChain OpenAI wrapper (reads OPENAI_API_KEY from env)
        self.llm = OpenAI(model="gpt-4o-mini", temperature=0)
        workflow = StateGraph(CodeState)
        workflow.add_node("start_analysis_node", self.start_analysis_node)
        workflow.add_node("optimize_code_node", self.optimize_code_node)
        workflow.add_node("correct_code_node", self.correct_code_node)

        # Define entry and transitions
        workflow.set_entry_point("start_analysis_node")
        # Conditional edges from analyzer node
        workflow.add_conditional_edges("start_analysis_node",
                                       self.conditional_next_node,
                                       {"optimize_code_node": "optimize_code_node",
                                        "correct_code_node": "correct_code_node"})
        # Cycle back from corrector to analyzer
        workflow.add_edge("correct_code_node", "start_analysis_node")
        self.graph = workflow.compile()



    def llm_check_code_syntax(self,code: str) -> bool:
        prompt = (
            "Check if the following Java code is syntactically correct. "
            "Reply ONLY with 'correct' or 'incorrect'.\n\n"
            f"Java code:\n{code}\n\nAnswer:"
        )
        result = self.llm(prompt)
        return result.strip().lower() == "correct"

    def llm_correct_code(self,code: str) -> str:
        prompt = (
            "Correct the following Java code to be syntactically valid. "
            "Provide only the corrected code without explanations.\n\n"
            f"Java code:\n{code}\n\nCorrected Java code:"
        )
        return self.llm(prompt).strip()

    def llm_optimize_code(self,code: str) -> str:
        prompt = (
            "Optimize the following syntactically correct Java code "
            "for readability and performance. Return only Java code with no explanation and no markdown.\n\n"
            f"Java code:\n{code}\n\nOptimized Java code:"
        )
        return self.llm(prompt).strip()

    # The analyzer node sets 'is_correct' in state to guide conditional branching,
    # no explicit goto inside the node function.
    def start_analysis_node(self,state:CodeState):
        code = state["code"]
        print("Analyzer: Checking syntax via LLM...")
        is_correct = self.llm_check_code_syntax(code)
        print(f"Analyzer: Code is {'correct' if is_correct else 'incorrect'}")
        return Command(update={"is_correct": is_correct})

    # Optimizer node - performs optimization and ends the workflow.
    def optimize_code_node(self,state:CodeState):
        code = state["code"]
        print("Optimizer: Optimizing code via LLM...")
        optimized_code = self.llm_optimize_code(code)
        print("Optimizer: Optimization complete. Ending workflow.")
        return Command(update={"code": optimized_code}, goto=END)

    # Corrector node - fixes syntax errors; no goto, flow cycles via explicit edge.
    def correct_code_node(self,state:CodeState):
        code = state["code"]
        print("Corrector: Correcting code via LLM...")
        corrected_code = self.llm_correct_code(code)
        print("Corrector: Correction complete. Returning to analyzer.")
        return Command(update={"code": corrected_code})

    # Branching function to decide next node after analyzer based on 'is_correct'.
    def conditional_next_node(self,state:CodeState):
        return "optimize_code_node" if state.get("is_correct") else "correct_code_node"

    def run_workflow(self,code):
        initial_state = {
            "code": code,
            "is_correct": True  # 'analyzer' will set this value at the beginning
        }

        print("Starting the execution of the workflow with invoke()...\n")

        # Run the workflow and get the final state
        final_state = self.graph.invoke(initial_state)

        print("\nWorkflow completed!")
        print("-" * 50)
        print("Final Java code (corrected and optimized):\n")
        print(final_state["code"])
        print("-" * 50)
        print(f"Final 'is_correct' state: {final_state['is_correct']}")

    def get_graph(self):
        return self.graph.get_graph()


def run_code_validation_flow():

    initial_code = """
    public class Test {
        public static void main(String[] args) {
            System.out.println("Hello World!")
        }
    }
    """

    initial_state = {
        "code": initial_code,
        "is_correct": True  # 'analyzer' will set this value at the beginning
    }

    print("Starting the execution of the workflow with invoke()...\n")

    graph=JavaVerifierGraph()
    final_state = graph.run_workflow(initial_state)


    return graph

if __name__ == "__main__":
    graph=run_code_validation_flow()
    # This command generates the PNG data as bytes, which works outside of Jupyter
    mermaid_png_bytes = graph.get_graph().draw_mermaid_png()

    # Specify the filename for the output image
    output_filename = "langgraph_workflow.png"

    try:
        # Open the file in binary write mode ('wb')
        with open(output_filename, "wb") as f:
            # Write the image bytes to the file
            f.write(mermaid_png_bytes)
        print(f"Diagram sevaed on {output_filename}")
    except Exception as e:
        print(f"Error during diagram generation: {e}")

Mental Model: With LangGraph, you build the workflow by explicitly defining a state schema, followed by individual nodes (functions). You then connect these nodes with edges. The orchestration logic is literally a graph you construct, giving you a powerful, albeit more complex, low-level tool for state management.

Conclusion

I appreciate CrewAI’s lean, quick-to-launch workflows and developer experience, which speed up prototyping and smaller scope projects. The Flow feature adds a layer of explicit control that bridges the gap with more low-level frameworks. Meanwhile, LangGraph stands out for heavyweight, scalable AI pipelines in enterprise-grade systems with a need for full-control graph orchestration.

To gain a more complete understanding of each framework's workflow implementation capabilities, other critical aspects must be considered. These include state management, the ability to handle state persistence (saving and resuming a workflow), and the ease of implementing a Human-in-the-Loop (HITL) scenario. These factors are crucial for designing robust, long-running processes that require durability or external intervention.

For the time being, CrewAI fits my development style best, but I watch LangGraph’s evolution with interest as it appears to be solidifying its place as the go-to framework for complex AI agent orchestration at scale.

Crewai

rosidotidev — Wed, 30 Jul 2025 18:47:56 +0000

Spring.ai

rosidotidev — Sun, 27 Jul 2025 13:19:05 +0000

crew

rosidotidev — Sun, 20 Jul 2025 19:40:07 +0000

CrewAI meets RAG: built-in and custom solutions

rosidotidev — Sun, 20 Jul 2025 12:55:25 +0000

(Originally published on my blog: https://roby73.hashnode.dev/crewai-meets-rag-built-in-and-custom-solutions)

Generative AI offers immense possibilities, however to truly be effective in real-world applications, it needs to overcome key hurdles: ensuring accuracy and integrating with private, up-to-date company information. A standard Large Language Model (LLM) on its own often isn't enough for tasks demanding specific facts and deep domain knowledge. LLMs generate responses based solely on their training data. If they lack a direct answer, they might still attempt one, sometimes leading to convincing, yet fabricated, outputs (often referred to as hallucinations). For serious applications that demand reliable, grounded results, a smarter approach is essential.

Understanding RAG: The secret to accurate AI

This is where Retrieval Augmented Generation (RAG) comes in. Think of RAG as giving the LLM a set of specific notes to read before it answers a question. This makes its responses accurate and based on real data. The RAG process can be broadly divided into two main phases: Ingestion and Retrieval, both crucial for augmenting the LLM's knowledge.

RAG Ingestion Phase

This initial phase focuses on preparing your knowledge base.

Document Loading: Documents from various sources (PDFs, text files, database schemas, etc.) are loaded into the system.

Transformation (Chunking): Loaded documents are often too large to be processed all at once. They are broken down into smaller, manageable "chunks" or segments. This process might also involve cleaning or pre-processing the text.

Embedding: Each text chunk is then converted into a numerical representation called an embedding. This transformation is performed by an embedding model (e.g., a Sentence Transformer or a model like OpenAI's text-embedding-3-small). Embeddings capture the semantic meaning of the text, allowing for comparisons based on context rather than just keywords.

Persistence (Vector Database): These embeddings, along with references back to their original text chunks, are stored in a Vector Database (Vector DB). A Vector DB is optimized for efficiently storing and querying high-dimensional vectors, enabling fast similarity searches.

RAG Retrieval Phase

This phase occurs when a user submits a query to the Generative AI application.

Query Embedding: The user's input query is also converted into an embedding using the same embedding model that was used during the Ingestion phase. This ensures consistency in the vector space.

Similarity Search: The query embedding is then used to perform a similarity search within the Vector DB. The goal is to find the "closest" or most semantically similar text chunks (and their corresponding original content) to the user's query.

Contextual Augmentation: The relevant text chunks retrieved from the Vector DB serve as precise, up-to-date information. This retrieved context is then used to enrich the original user query, forming a new, more informed prompt.

LLM Interrogation: Finally, this augmented prompt (containing both the user's original request and the relevant retrieved context) is fed to the Large Language Model. The LLM then generates a factual and grounded response, drawing directly from the specific knowledge extracted from your knowledge base, significantly reducing hallucinations and increasing reliability.

Why RAG is a Game-Changer

RAG isn't just about accuracy; it solves critical problems:

Precision and Reliability: RAG ensures the LLM's answers are factually correct and you can trace them back to your trusted data. This significantly reduces the chance of hallucinations.

Cost Optimization: Giving the LLM the right context with RAG means you don't need super long, complex prompts. Getting data (like for embeddings) is usually much cheaper than writing huge prompts or paying for more LLM tokens.

Overcoming Token Limits: All LLMs have a maximum amount of text they can handle at once (their context window). RAG smartly gets around this by only giving the most relevant bits of information, instead of trying to stuff an entire knowledge base into the prompt. This lets LLMs work with much bigger and more complex data sets.

CrewAI: Orchestrating Smart Agents for flexible RAG

CrewAI is a powerful Python framework. It lets you create and manage teams of autonomous AI agents. With CrewAI, you can define specialized agents (like a "Researcher" or an "Analyst") with specific roles, goals, and tools. CrewAI is key for RAG because it allows these agents to work together and share tasks. This makes the RAG process strong and efficient. The "Tools" are the crucial link, connecting your agents to all your different knowledge sources. Flexibility is key: CrewAI lets you use both built-in RAG features that come with the framework (like PDFSearchTool and Knowledge) and custom tools you build yourself. This means you can connect to any specific data source you need, which is essential for real-world projects.

Implementing RAG with CrewAI: Three Practical Approaches

Here's how you can use CrewAI to implement RAG, showing its versatility.

Native RAG Tools

This is how CrewAI handles RAG natively using its built-in tools. The PDFSearchTool is a prime example, designed for semantic searches directly within PDF content. A CrewAI agent can use this out-of-the-box tool to efficiently find and retrieve specific passages based on a search query within a PDF document. By default, it uses OpenAI for both embeddings (to understand meaning) and summarization, though this can be customized. This automates knowledge extraction from your existing PDF archives directly within the CrewAI ecosystem.

Knowledge for Document-Based RAG

CrewAI offers a native "Knowledge" feature that allows agents and crews to directly access and utilize various external information sources. This acts as a built-in reference library for your agents. You can provide knowledge sources in formats like raw strings, .txt, .pdf, .csv, .xlsx, and .json documents by placing them in specified directories. CrewAI handles the storage (using ChromaDB by default) and embedding automatically. This approach empowers agents with direct access to a curated document set, ensuring their responses are grounded in your specific data.

Custom tool that uses Vector Search (FAISS in our case)

FAISS (Facebook AI Similarity Search) is great for very fast searches based on meaning, across huge sets of data (vector embeddings). Here, a custom tool lets CrewAI agents query a FAISS index. They find information that's semantically similar and feed it to the LLM. This provides fast and scalable semantic search for large, changing knowledge bases.

Real-World Example: Demonstrating RAG Flexibility with Multi-Crew Setup

In a real-world project, we implemented a system to analyze PDF documents. This setup, whose code is available in this repository: CrewAI-RAG-Sample, effectively demonstrated CrewAI's versatility.

├── db
│   ├── 455d85ec-a7f9-4c9c-82d8-d3567d9263aa
│   └── chroma.sqlite3
├── Easy_recipes.pdf
├── knowledge
│   └── Easy_recipes.pdf
├── LICENSE
├── main.py
├── Pipfile
├── Pipfile.lock
├── ragcrew
│   ├── config
│   │   ├── agents.yaml
│   │   └── tasks.yaml
│   ├── faiss_rag_crew.py
│   ├── pdf_knowledge_crew.py
│   ├── tool_rag_crew.py
│   └── tools
│       └── custom_tool.py
├── README.md
├── report.md
└── setup.txt

We achieved this by employing three distinct crews, executed one after the other, to reach the same analytical goal. What made each crew unique was the specific RAG approach it utilized, while the core agents and tasks remained consistent. This allowed for a direct comparison of RAG strategies in action.

Each of these three crews was designed with the same set of specialized agents, for instance, a PDF Researcher and a Content Analyst. Similarly, the tasks they performed were identical across all crews: first, Information Retrieval to locate and extract relevant data from the PDF based on a user query; then, Content Refinement to process and summarize the retrieved information for clarity and conciseness; and finally, Output Generation to format and save the final, refined content into a Markdown (.md) file.

The key differentiator lay in how each crew performed its Information research task declared within the tasks.yaml file. This task relies on pdf_researcher Agent.

research_task:
  description: >
    Search for specific information requested in the {topic}.
  expected_output: >
    Most relevant information about {topic},
  agent: pdf_researcher

content_task:
  description: >
    Review the context you got.
    Make sure the report is detailed and contains any and all relevant information.
  expected_output: >
    A fully fledged report with the main topics. The language to use is the language of the request "{topic}",

Let’s see how the three crews manage RAG different approaches.

ToolRagCrew: This crew leveraged CrewAI's out-of-the-box PDFSearchTool for its RAG mechanism. Agents directly queried PDF documents, showcasing a straightforward, native approach to unstructured document RAG. Here a Python code snippet for tool_rag_crew.py

    . . . 
    from crewai_tools import PDFSearchTool
    . . .
    @CrewBase
    class ToolRagCrew:
        agents: List[BaseAgent]
        tasks: List[Task]
        . . .
        def getPDFRagTool(self):
            if self.pdf_tool is None:
                self.pdf_tool = PDFSearchTool(pdf=self.pdf_path,
                                              #chunker=dict(chunk_size=2000,chunk_overlap=50)
                                              )
            return self.pdf_tool
        @agent
        def pdf_researcher(self) -> Agent:
            return Agent(
                config=self.agents_config['pdf_researcher'],
                verbose=True,
                tools=[self.getPDFRagTool()],
            )
        . . .

How you can see, a built in PDFSearchTool is configured as a tool for the PDF Researcher Agent

PDFKnowledgeCrew: Here, the crew utilized CrewAI's native "Knowledge" feature. PDF documents were pre-loaded into the agents' knowledge base by placing them in a designated directory, allowing agents to access and integrate this curated information during their tasks. Here a Python code snippet for pdf_knowledge_crew.py

    . . . 
    from crewai.knowledge.source.pdf_knowledge_source import PDFKnowledgeSource
    . . .
    @CrewBase
    class PDFKnowledgeCrew:
        agents: List[BaseAgent]
        tasks: List[Task]
        . . .
        def get_knowledge_sources(self):
            if self.pdf_source is None:
                self.pdf_source = PDFKnowledgeSource(file_paths=self.pdf_paths)
            return self.pdf_source

        @agent
        def pdf_researcher(self) -> Agent:
            return Agent(
                config=self.agents_config['pdf_researcher'],  # type: ignore[index]
                verbose=True,
                knowledge_sources=[self.get_knowledge_sources()]
            )
        . . .

How you can see, it is very simple to use Knowkedge feature with Crew. You have to use the attribute knowledge_sources within the Agent declaration. It accepts an array of instances of PDFKnowledgeSource. That’s it!

FAISSRagCrew: For this crew, a custom tool integrated with FAISS was implemented. This represented a more scalable solution for large datasets, where agents used this custom tool to perform semantic searches on vector embeddings derived from the PDF content. I’ve used FAISS (Facebook AI Similarity Search) because this library is very useful for similarity search and clustering of vectors. I also wanted to share how CrewAI framework is “opened” for integration with 3rd party libraries and tools. Here a Python code snippet for faiss_rag_crew.py

    . . .
    import pdfplumber
    from langchain.text_splitter import RecursiveCharacterTextSplitter
    from langchain_community.vectorstores import FAISS
    from openai import OpenAI
    from typing import List
    from langchain_openai import OpenAIEmbeddings  
    from ragcrew.tools.custom_tool import PDFFAISSTool

    @CrewBase
    class FAISSRagCrew:

        agents: List[BaseAgent]
        tasks: List[Task]

        def __init__(self,pdf_path):
            self.pdf_path=pdf_path
            self.vector_store= None
            self.client=OpenAI()
            self.search_tool=None

        def get_openai_embedding(self,text):
            response = self.client.embeddings.create(
                input=text,
                model="text-embedding-3-small"
            )
            return response.data[0].embedding

        def load_pdf(self):
            with pdfplumber.open(self.pdf_path) as pdf:
                return " ".join(page.extract_text() for page in pdf.pages)

        def prepare_rag(self,pdf_text):
            text_splitter = RecursiveCharacterTextSplitter(
                chunk_size=2000,
                chunk_overlap=200
            )
            chunks = text_splitter.split_text(pdf_text)
            return FAISS.from_texts(chunks, OpenAIEmbeddings())

        def initFAISS(self):
            pdf_text = self.load_pdf()
            self.vector_store = self.prepare_rag(pdf_text)
            self.search_tool = PDFFAISSTool(self.vector_store)

        @agent
        def pdf_researcher(self) -> Agent:
            self.initFAISS()
            return Agent(
                config=self.agents_config['pdf_researcher'],  # type: ignore[index]
                verbose=True,
                tools=[self.search_tool]
            )
        . . .

How you can see, within the Agent declaration the initFAISS() method is invoked. It executes the ingestion phase of the RAG process: loading of the PDF file, persisting embedded data into the vector DB, and initialization of the PDFFAISSTool which is a custom tool defined in the project.

This multi-crew sample effectively highlights CrewAI's ability to maintain consistent operational logic (same agents, same tasks) while allowing for flexible and interchangeable RAG strategies.

Conclusion: Takeaways of the reading

In this article, we looked at different ways to set up Retrieval-Augmented Generation (RAG) within a CrewAI agent system. We saw how each method: using a special PDFSearchTool, the built-in Knowledge feature of CrewAI, and making a Custom Tool with FAISS, offers different ways to help our agents find and use outside information. We learned that all three methods aim to give Large Language Models (LLMs) the right information to create accurate answers and avoid making things up. But they are different in their purpose, how the agent uses the data, and how much control you have. What is clear is that CrewAI is a capable framework for building systems with many agents. Alongside other agent frameworks like LangChain, AutoGen, or LlamaIndex, CrewAI provides a valuable alternative. It is easy to use and focuses on how agents work together, what their jobs are, and what they want to achieve.

Trading

rosidotidev — Fri, 21 Mar 2025 22:53:12 +0000

Simplifying backlog management on Jira with CrewAI

rosidotidev — Sun, 19 Jan 2025 21:29:19 +0000

One of the key challenges in the Agile development lifecycle is defining User Stories with the right level of detail. During refinement phases, stories can range from being overly generic and high-level to fully detailed and actionable. This variability often leads to inefficiencies and inconsistencies in backlog management.

By leveraging a workflow of Generative AI agents capable of interacting with Jira's APIs (tools), we can automate backlog creation and refinement. These agents process requirements, enrich them with best practices, and interact directly with Jira to generate and organize backlog items. The workflow is designed to:

Break down requirements into structured Epics and User Stories.
Suggests stories in a structured and formalized format.
Seamlessly interface with Jira to update or query backlog items dynamically.

In this article we see how CrewAI framework can be used to reach this goal, it is a cutting-edge platform designed to orchestrate autonomous AI agents, enabling them to collaborate effectively on complex tasks.

Key components of CrewAI include:

Agents: Autonomous units with specific roles, expertise, and responsibilities. Each agent can perform tasks, utilize tools, and collaborate with other agents to achieve shared objectives.
Tasks Defined objectives assigned to agents, which can be executed sequentially or in parallel. Tasks are the building blocks of the workflow, guiding agents on what needs to be accomplished.
Tools Integrated functionalities that agents can employ to interact with external systems, such as APIs. For instance, agents can use tools to interface with Jira's API, enabling operations like creating issues or retrieving data.
Crews A crew in crewAI represents a collaborative group of agents working together to achieve a set of tasks. Each crew defines the strategy for task execution, agent collaboration, and the overall workflow.

By defining these components, CrewAI facilitates the creation of AI teams where each agent has specific roles, tools, and goals, working together to accomplish complex tasks. This structured approach ensures efficient collaboration and effective task execution within the framework. The basic idea is to define the 4 main capabilities using a friendly and basic UI.

1. Detailed Backlog Creation from Requirements

CrewAI agents process requirement descriptions and generate tasks enriched with security considerations, architectural patterns, and testing protocols. Whether a requirement is sparse or well-documented, the system produces actionable Epics and User Stories, aligning with best practices and reducing manual effort.

2. Collaboration with Product Owners

Tasks are automatically grouped into Epics and linked to User Stories with pre-defined acceptance criteria. Product Owners can easily review, adjust, and reprioritize tasks, ensuring alignment with project goals while reducing time spent on refinement.

3. Automated Jira Integration

The system integrates seamlessly with Jira, creating and organizing Epics and User Stories directly within the tool. This eliminates manual data entry, ensuring consistent and efficient backlog management.

4. Advanced Search and Filtering

With natural language queries and advanced filters (e.g., by priority, status, or assignee), the system can quickly navigate large backlogs, locate tasks, and identify gaps or dependencies to optimize task management.

Implementation overview

In this github project there is a basic implementation of these capabilities. This is the project structure

├── agents
│   ├── agile.py
│   └── reporter.py
├── tasks
│   ├── agile.py
│   └── reporter.py
├── tools
│   ├── easy_jira_wrapper.py
│   ├── jira_cleaner_util.py
│   ├── jira_epic_creator_tool.py
│   ├── jira_reader_tool.py
│   └── jira_story_creator_tool.py
├── crews.py
├── LICENSE
├── main.py
├── main_web_gradio.py
├── Pipfile
├── Pipfile.lock
├── README.md
├── setup.txt
├── statememnts_repo.py
└──web_app_gradio.py

main.py: Backend entry point for CrewAI workflows.
main_web_gradio.py: Entry point for the Gradio-based web interface.
web_app_gradio.py: Logic for the web app, handling user inputs and outputs.
crews.py: Defines Crews, collections of agents and tasks.
statememnts_repo.py: Repository for prompts, queries, or agent instructions.
README.md: Documentation for installation and usage.
LICENSE: Project licensing information.
Pipfile & Pipfile.lock: Dependency management with pipenv.
setup.txt: Instructions for initializing the project.

`agents`

Defines AI agents specialized in specific tasks:

agile.py: Agents for Agile processes like backlog refinement.
reporter.py: Agents for generating Jira-related reports.

`tasks`

Specifies objectives for agents:

agile.py: Tasks for creating Epics and User Stories.
reporter.py: Tasks for generating reports.

`tools`

Utilities for Jira integration:

easy_jira_wrapper.py: Simplified wrapper for Jira API operations.
jira_cleaner_util.py: Tool for cleaning outdated issues.
jira_epic_creator_tool.py: Automates Epic creation.
jira_reader_tool.py: Reads and filters Jira issues.
jira_story_creator_tool.py: Creates and links User Stories. ## User Interface

The user interface is designed for simplicity and functionality:

Input Area: Located in the top-left corner, this text area allows users to input their requirements or queries for the system.
Output Area: Positioned at the bottom, this section displays the system's response, including generated backlogs or Jira issue details.
Dropdown Menu: Found in the top-right corner, the dropdown provides the following options:

Create a Backlog and Jira User Stories on Jira

The user can enter a requirement (even just a few words) into the input area, then the system processes the input, generates a backlog, and saves it in Jira as an Epic with linked User Stories.

The output includes the Type, Key, Summary, and Description of all Jira Stories in Markdown format.
Create a Backlog

This option allows the user to generate a backlog based on the input requirement. The user can review and modify the backlog before submitting it to Jira with the next choice.
Create Jira User Stories on Jira

Use this option to submit a pre-defined or previously created backlog to Jira, where it will be saved as Epics and Stories.
Retrieve Jira Issues

This feature allows users to query Jira and retrieve existing issues based on specific criteria.

The interface provides a streamlined experience, ensuring users can efficiently manage backlogs and interact with Jira. Below an example of what can be created on Jira with this tool.

Conclusions

This project serves as a concrete example of how Agentic Generative AI can support a specific phase of the software development lifecycle. By automating the backlog creation and refinement process, it showcases the potential of AI agents to reduce manual effort, enhance consistency, and streamline Agile workflows.

CrewAI proves to be a strong competitor in the growing landscape of agentic frameworks, standing alongside platforms like LangGraph, LlamaIndex, AutoGen, and many others. Its flexibility in defining agents, tasks, and tools makes it a valuable choice for building advanced AI-driven workflows.

That said, the project is currently in a prototypal state and has room for improvement in several key areas:

Integration of a Retrieval-Augmented Generation (RAG) approach: To enhance contextual accuracy by combining AI outputs with real-time data retrieval.
Improved Input and Output Typing with Pydantic: Strengthening data validation and consistency across the workflow.
Agent and Task Abstraction: Introducing support for YAML-based configuration files to simplify the definition and customization of agents and tasks.
Expanded Jira Interactions: Adding more diverse operations to interact with Jira, such as advanced queries, bulk updates, and custom workflows.

This prototype highlights the immense potential of CrewAI and similar frameworks, demonstrating how they can revolutionize software development processes with intelligent, automated workflows.

GenAI meets Jira: Transforming CSV Exports into Insights

rosidotidev — Mon, 20 May 2024 19:09:30 +0000

As a passionate developer with many years of experience, I've witnessed the evolution of technology and its impact on the way we handle data. While traditional methods have served us well, the advent of Generative AI (GenAI) presents a transformative opportunity for data analysis. Today, I want to share my journey into this exciting new world by exploring how GenAI can revolutionize the way we interact with and analyze data exported from Jira.

Jira, a popular project management tool, is widely used to track tasks, bugs, and project progress. It offers the capability to export data into CSV files, which can then be analyzed to gain insights. However, the manual process of sifting through these CSV files can be tedious and time-consuming. This is where GenAI steps in.
Imagine being able to query your Jira exports using natural language, extracting meaningful insights effortlessly. With the combination of LangChain, OpenAI's powerful language model, and the pandas library, we can create an intelligent agent capable of interpreting and executing complex queries on Jira data exports. This not only simplifies the analysis process.
In this article, I'll walk you through how GenAI can be applied to Jira CSV exports, transforming raw data into actionable insights with ease. We'll delve into a project that leverages these cutting-edge technologies to demonstrate the potential of GenAI in revolutionizing our approach to data analysis.

While it is possible to use a Jira agent developed by LangChain, I chose to work with a CSV file that closely resembles the format of an export from Jira. This decision was made to simplify the demonstration and to avoid to connect to the Jira instance of your Company :). The data in the CSV file used for this project was generated in a nearly random manner to serve as an example.

Let's Start

To get started with this project, you'll need an OpenAI API key. You can obtain this key by subscribing to the OpenAI service on their website. Once you have your API key, save it in a .env file at the root of the project. The .env file should look like this:

OPENAI_API_KEY=your-api-key-here

Next, you need to install the necessary libraries. You can do this using pipenv with the following command:

pipenv install pandas numpy python-dotenv langchain langchain-openai openai langchain-experimental tabulate streamlit streamlit-chat

For this project, I used PyCharm, but you can use any other Python IDE such as VS Code or any editor of your choice.

The entire project is available in my GitHub repository langchain_pandas_agent. In this repository, under the csv_dir directory, you will find a CSV file containing tasks for a fictional eCommerce project.

The teams Baggio, Buffon, Del Piero, Mancini, Materazzi, and Zola are working on this project, and the file includes both Technical and Functional tasks recorded over three sprints.

The Main Script

The core of our project is encapsulated in the main.py script, which orchestrates the interaction between various components. Let's take a closer look at how it's structured:

from dotenv import load_dotenv
from agent_manager import getAgentExecutorChatOpenAI
from df_manager import read_df

def ask(query):
    df = read_df()
    agent_executor = getAgentExecutorChatOpenAI(df)
    response = agent_executor.invoke(query)
    return response

def start_web_app():
    from web_app import build_web_app
    build_web_app(ask=ask)

if __name__ == '__main__':
    load_dotenv()
    start_web_app()

Explanation

Imports: The script begins by importing necessary modules:
- load_dotenv from dotenv to load environment variables.
- getAgentExecutorChatOpenAI from agent_manager to create the agent executor.
- read_df from df_manager to read the DataFrame.
ask Function: The ask function is designed to handle the queries. It reads the DataFrame using read_df(), initializes the agent executor with getAgentExecutorChatOpenAI(df), and invokes the agent with the given query to obtain a response. This function essentially acts as the bridge between the user input and the underlying data processing logic.
start_web_app Function: This function sets up the web application. It imports build_web_app from web_app and calls it, passing the ask function as a parameter. This function ensures that the web app is equipped to handle user queries through a streamlined interface.
Main Execution: The script concludes with a standard Python convention: checking if the script is being run directly. If it is, it loads the environment variables using load_dotenv() and starts the web application by calling start_web_app().

Key Components

Web Application: The web application is built using the Streamlit framework, which allows for the creation of interactive web interfaces with minimal effort. Streamlit is ideal for data apps, providing a smooth and intuitive user experience.
Dataframe reader: This module contains the logic related to the reading and lightweight processing of the pandas dataframe.
Agent Manager: The agent_manager module contains the logic related to LangChain and OpenAI. It is responsible for creating and managing the intelligent agent that processes natural language queries and interacts with the data.

Reading the CSV: `df_manager.py`

The df_manager.py file contains a function to read and preprocess our CSV data from Jira.

import pandas as pd

def read_df():
    file_name = "csv_dir/Jira_Issues_Simulation_Final_With_Dates.csv"
    df = pd.read_csv(file_name, sep="|")
    df['Category'] = df['Labels'].apply(lambda x: str(x).split(',')[0].strip() if ',' in str(x) else '')
    df['Team'] = df['Labels'].apply(lambda x: str(x).split(',')[1].strip() if ',' in str(x) else '')
    return df

It mainly uses three steps:

Read the CSV: The read_df function reads the CSV file located in the csv_dir directory using pandas, with a pipe (|) as the separator.
Process Labels: It extracts Category and Team from the Labels column, assuming labels are comma-separated.
Return DataFrame: Finally, it returns the processed DataFrame ready for analysis.

This simple script ensures that our data is correctly loaded and preprocessed, making it ready for the natural language queries handled by our LangChain agent.

Creating the Agent: `agent_manager.py`

The agent_manager.py file contains the logic for creating the LangChain agent using OpenAI's GPT-3.5-turbo model.

from langchain_experimental.agents.agent_toolkits import create_pandas_dataframe_agent
from langchain_openai import ChatOpenAI, OpenAI

def getAgentExecutorChatOpenAI(df):
    prefix = """
           Use the column Team to retrieve the team;
           technical or functional refer to the column category;
           Consider that the single row can be called ECOM;
           Consider that state refers to column Status;
           The URL of an ECOM is https://robby.com/{Issue Key}, where {Issue Key} is the value of the column "Issue Key"
          """
    agent = create_pandas_dataframe_agent(
        ChatOpenAI(temperature=0, model="gpt-3.5-turbo-0613"),
        df,
        prefix=prefix,
        verbose=True,
        return_intermediate_steps=True,
        agent_type="openai-tools",
        max_iterations=10,
        agent_executor_kwargs={"handle_parsing_errors": True}
    )
    return agent

Even here we can describe mainly three steps:

Imports: The script imports necessary modules:
- create_pandas_dataframe_agent from langchain_experimental.agents.agent_toolkits.
- ChatOpenAI and OpenAI from langchain_openai.
getAgentExecutorChatOpenAI Function: This function creates and configures the LangChain agent.
- Prefix Instructions: A prefix is provided to guide the agent on how to interpret certain columns in the DataFrame. I've added these prefix statements after many attempts. To be honest, I was very impressed when I was able to explain how to build the URL even id I'm not an expert on prompt engineering
- Agent Creation: The agent is created using the create_pandas_dataframe_agent function with several parameters:
  - ChatOpenAI: The language model is set to gpt-3.5-turbo-0613 with a temperature of 0 for deterministic responses.
  - df: The DataFrame that the agent will interact with.
  - prefix: Instructions to guide the agent.
  - verbose: Enables detailed logging.
  - return_intermediate_steps: Returns intermediate steps for debugging.
  - agent_type: Specifies the type of agent as openai-tools.
  - max_iterations: Limits the number of iterations to 10.
  - agent_executor_kwargs: Additional arguments to handle parsing errors gracefully.
Return Agent: Finally, the configured agent is returned for use in querying the DataFrame.

This setup equips our LangChain agent with the ability to process natural language queries on the Jira CSV data, leveraging the power of OpenAI's model. It's worth describing that in this case we've used GPT-3.5-turbo model, but with few changes it is possible to switch to a local llm or to a different llm (ie: Google Gemini)

Building the Web Application: `web_app.py`

The web_app.py file sets up a web interface using Streamlit, allowing users to interact with the LangChain agent through natural language queries.

import streamlit as st
from streamlit_chat import message
import uuid

def build_web_app(ask):
    def answer_request():
        if st.session_state.text_input:
            with st.spinner("Generating response..."):
                generated_response = ask(st.session_state.text_input)
                st.session_state.chat_history.insert(0, (st.session_state.text_input, generated_response["output"]))
                st.session_state.user_prompt_history.insert(0, st.session_state.text_input)
                st.session_state.chat_answers_history.insert(0, generated_response['output'])
            st.session_state.text_input=''

    st.header("LangChain🦜🔗 Jira facilitator example")
    if (
            "chat_answers_history" not in st.session_state
            and "user_prompt_history" not in st.session_state
            and "chat_history" not in st.session_state
            and "text_input" not in st.session_state
    ):
        st.session_state["chat_answers_history"] = []
        st.session_state["user_prompt_history"] = []
        st.session_state["chat_history"] = []
        st.session_state.text_input=''

    prompt = st.text_area("Prompt", key='text_input', on_change=answer_request)
    if st.session_state["chat_answers_history"]:

        for generated_response, user_query in zip(
                st.session_state["chat_answers_history"],
                st.session_state["user_prompt_history"],
        ):
            message(
                user_query,
                is_user=True,
                key=str(uuid.uuid4())
            )
            message(
                generated_response,
                is_user=False,
                key=str(uuid.uuid4())
            )

Two main points here:

Imports: The script imports necessary modules:
- streamlit as st for creating the web interface.
- message from streamlit_chat for chat message formatting.
- uuid for generating unique keys for chat messages.
build_web_app Function: This function sets up the Streamlit web application.
- answer_request Function: Handles user queries. When the user inputs a query, it invokes the ask function to generate a response and updates the chat history.
- Header: Sets the header of the web app.
- Session State Initialization: Initializes session state variables for storing chat history, user prompts, and generated responses.
- Prompt Input: Creates a text area for user input. When the input changes, answer_request is called.
- Display Chat History: Iterates over the chat history and displays user queries and generated responses using the message function.

This file creates a user-friendly web interface for interacting with the LangChain agent, enabling real-time natural language queries on the Jira CSV data.

Conclusion

I'm not a guru in Large Language Models (LLM) or Generative AI (GenAI), I am just beginning to explore the vast potential these technologies offer. The project we've discussed here is a small step into the transformative world of GenAI. The possibilities are truly endless, from simplifying data analysis to creating intelligent agents that can understand and process natural language queries.

This project is just an example of what can be achieved, and I encourage you to experiment and build upon it. As we continue to learn and adapt, we can look forward to a future where AI plays an integral role in our development processes.

Let's embrace this transformation and explore the endless opportunities that GenAI has to offer.

Just F*cking do it! Book takeaways

rosidotidev — Sun, 04 Feb 2024 12:05:37 +0000

Book written by Noor Hibbert and published in 2019. It has 242 pages distributed in 13 chapters. Each chapter ends with a Top Takeaways section and a JFDI! section.

Takeaways

Noor Hibbert is a powerhouse, and her book delivers a no-bullsh*t guide to transforming your life. Useful for professional coaches and IT experts, I found her approach refreshing and practical. Here’s why:

Psychological Rigor Meets Practical Wisdom: Just F*cking Do It combines psychological insights with actionable steps. Noor emphasizes that true personal development starts with changing our mindset and interactions. As coaches, we know that mindset matters, and this book reinforces that beautifully.
Law of Attraction for Success: Beyond the usual self-help fluff Noor dives into the Law of Attraction. She shows how aligning our thoughts with positive energy can multiply our success. As IT professionals, we understand the power of alignment – whether it’s code or life goals.
Content Accessible to a Diverse Audience: What sets this book apart is its versatility. It’s not just for seasoned self-help enthusiasts; it’s for us – the coaches, the tech wizards, the problem solvers, Software Architects designing new solutions. Noor’s candid style resonates across diverse audiences, making this a must-read for anyone seeking growth and transformation.
Beyond the Buzzwords: Noor doesn’t sugarcoat. She challenges us to stop thinking small, cut through the noise, and take action. As IT experts, we appreciate practical advice that cuts to the chase. In summary, Just F*cking Do It is a wake-up call for those who want to break free from mediocrity. Whether you’re coaching clients or debugging code, this book will throw away your excuses and push you towards your best life.

The Book

In the first 3 chapters the author talks about how her life was changed once she adopted what she reports in the book. Talk about the Law of Attraction: to achieve things you have to think positively and think that things will happen. She talks about the positive vibes you have with the Universe entity. The Law of Attraction allows you to decide what you get out of life. The right way to synchronize with the Universe is by using Radio Universe if it connects us using a negative, short-tempered approach you are using Radio Shit. The author underlines that people's freedom is determined by having objectives in the 8 areas that govern human happiness:

Spiritual
Emotional
Mental
Physicist
Relational
Professional
Financial

She suggests defining a maximum of 3 objectives for each area. To define them she suggests these precautions:

Write down your goals, don't just think about them
Define 5 very specific stages that are required to achieve the objective
Set a deadline
Write the objectives in the present tense, as if they had already been achieved
Think of 5 things you would think, believe and feel once you reach your goal and re-read it often

Once the objectives have been defined, we should not be surprised if we are unable to achieve them by the expected date or through the planned stages. Changes are often decided by the Universe in an irrational way

The writer defines 2 voices that are within us, the Ego and the Soul. The Ego is that part that always justifies us, that blames others when we don't succeed, that makes us angry when a car cuts us off. The Soul, on the other hand, is that positive voice that pushes us to smile when someone cuts us off, that makes us smile and get along with others.

In chapters 4,5,6 the author describes three fundamental aspects to prepare to become the best version of ourselves:

Knowing how to look inside ourselves: we must look inside ourselves to understand where we want to go, who we want to become. Social media often leads us to define models and objectives that are not ours, which only serve to satisfy others.
Recognize your limiting beliefs: when we look inside ourselves we must be able to identify our limiting beliefs. We are often blocked in our evolution because we have incorporated beliefs in the first years of life. We were not born with these beliefs, we absorbed them from the context in which we grew up. Once identified, we need to understand when we have received them and from whom so that we can chase them away using self-awareness and a technique such as Tapping.
Visualize who you want to be: once you have identified the external and internal noises you need to proceed to the self-forgiveness phase (spiritual facelift). That is, we need to reset the Ego which is the collector of these disorders and we need to visualize who and how we need to be to achieve the objectives and trigger change. Visualization is learned with practice.

In the following 3 chapters Nori Hibbert describes the main steps to define the best version of yourself:

Choose yourself: you need to know how to forgive yourself and others at all times, even if unpleasant things happen you need to look at the positive side of things and think about how to transform that event into a positive one. Furthermore, you need to be selfish to the right degree and celebrate yourself every day.
Your word is your magic wand: our internal and external dialogues are crucial in defining who and how we are. It is enough to change some words that we usually use and the perspective changes from pessimistic to optimistic.
Not all karma is the same: every day we deal with karma, even when it manifests itself adversely we must accept it and not be discouraged by negative events. We must be aware that the choices we make are decisive for our future. We need to be “more crab”. The crab periodically recycles its carapace based on the growth of its body; in practice it is a metaphor to push us to often leave our comfort zone, to take risks, in order to grow more than those around us who do not necessarily have to be our growth model.

In the final chapters sher goes beyond the basics defined in the previous chapters and focuses on more advanced aspects:

Google doesn't know all the answers: we often search for answers on Google but we have a very powerful weapon that we don't know how to exploit: intuition. Intuition is often magically precise; it is the means by which The Universe speaks to our Soul.
Exercise gratitude: gratitude is the frequency of love. The more we distribute, the more we get back. We must not spare ourselves to express gratitude when it is sincere and true.
The power of your circle: we are the sum of the 5 people we hang out with the most, so surrounding ourselves physically and virtually (via social media) with the right people is essential. We need to cut the cord with negative people, let's not give too much importance to the advice of those who have not been able to achieve results in a certain context. In addition to being inspired by those around us, we must also inspire others; questions are better than advice.
Don't just say it, do it, get to the bottom of it: it's not enough to know and talk about everything the book has covered up to this point, you have to put it into practice. There are two things that often prevent you from taking action: the pursuit of perfection and procrastination. It is better to have achieved a goal even if not perfectly or incompletely than to not have tried at all.

Flutter 2.0 meets Nimbella

rosidotidev — Sun, 21 Mar 2021 14:46:01 +0000

I'm a developer and a Flutter fun and, some weeks ago, I was waiting for March 3rd 2021 Flutter Engage.

Once known that Fultter 2.0 is "web stable" I began to think: "how can I test Flutter capabilities and its learning curve for the WEB?"

The idea

In that days I was studying a very nice serverless platform as Nimbella, looking at some Youtube videos. "Ok!" I said, "it's time to begin with both ones for a side PoC project"; thus I decided to implement a simple Todo List web application using Flutter for frontend and Nimbella serverless actions for backend. Studying Nimbella I discovered that it is possible to use it even as frontend server, where deploy something as html/js stuff but ... I decided to don't use this feature and use that PoC even to evaluate the GitHub pages.

Plan and Result

Ok, the plan is clear:

plan=Plan()
plan.phase[0]="Get a Nimbella free subscription"
plan.phase[1]="Develop and test a set of Python serverless actions"\
"(simple REST/CRUD services) for backend (Using Redis "\
"Nimbella connector as NoSql DB)"
plan.phase[2]=" Upgrade my Futter 1.22 platform to 2.0 and switch to web"\ 
" channel"
plan.phase[3]="Implement an MVP todo list web app with Flutter,"\
"using some widget and know-how got in another side project"\
" and connect to Nimbella services with Dio dart library"
plan.phase[4]="Deploy flutter build files to GitHub pages "
plan.run()

Simple right?
After 10 hours, spread over a whole week end, this is the result:

As you can see nothing exceptional :-) there could be a lot of improvements (adding a loading wheel, improve backend data api, improve error handling etc etc) but it works and It was useful to learn and experiment new frameworks and services. This web app has an entry page where you choose the username of the owner of the todo list; once entered there is a UI where with simple CRUD operations you can manage all todo items. It's worth noting that this webapp can be easily transformed to a PWA just adding it to Home screen from Chrome menu (on Android).

Phase 0 (Get a Nimbella free subscription)

It was very easy, at this link you can choose to start with a Nimbella free "Starter tier" service subscription that lets you create up to 25 functions; it's enough for basic projects and for leraning purpose.

Phase 1 (Python actions on Nimbella)

Here I've "monetized" previous studies on Nimbella looking at Youtube courses (1,2,3,4,5) but even reading https://docs.nimbella.com/ or Nimbella training. There you can find even how to install the nimbella cli that lets you execute all commands required to work with Nimbella platform.
If you want to take a complete look at the backend actions here you can find the github repo. Otherwise, you can see here one of the five Python actions used for the backend API.

import nimbella
import json
import random

def main(args):
    appkey='tdlst'
    db = nimbella.redis()
    item=args.get("content","")
    if item=='':
      return {"body":{"response":{"result":"error","description":"item not valid"}}}
    usercode=args.get("user-code","")
    if usercode=='':
      return {"body":{"response":{"result":"error","description":"user not valid"}}}
    n = random.randint(0,10000000)
    code="code-"+str(n)
    key = appkey+":item:"+usercode+":"+code

    value = json.dumps({
    "item": item,
    "user-code": usercode,
    "code": code})
    rsuccess=db.set(key, value)
    return {"body":{"response":{"result":"ok","code":code}}}

You are right! It's a simple Python main, where the args parameter wraps the json info passed through a simple HTTP request like this one:

curl -X POST "$URL_ITEM_ADD" -d '{"user-code": "code-6355808", "content": "buy a coffe"} ' -H 'Content-type: application/json'

The rest of the code is too easy to be commented, that's why Nimbella Python module allows to use redis in a very intuitive way. If you aren't a Python developer you can use other languages such as JavaScript, TypeScript, PHP, Java, Go, or Swif.
However there is a powerfull architecture behind the scenes that it's totally transparent for the developer

Very impressive! There are a set of architectural ingredients that enable a scalable serverless ecosystem.
Once you have written previous Python code, you need to execute this command to publish the serverless action on the cloud

nim action create api/item-save item-save.py --web true

nim is a powerfull commnd line interface (cli) provided by the platform that you can use in order to create new Nimbella projects, actions and even to directly test the actions.

Phase 2 (Upgrade to Flutter 2.0 for web development)

This is the phase where I was more afraid due to some issues I had in the past during Flutter upgrade (to be honest it happned during early Flutter realeases).

 $> flutter upgrade
 $> flutter config --enable-web

Instead it was quiet easy, I had just to upgrade to last version and then switch to web configuration (it's the mode that let you develop a web application)

Phase 3 (implement Flutter web app)

Here there is the project repository; it is how documentation states: developing a web application with Flutter 2.0 is very easy if you already know Flutter platform. I think the code is 99.99% the same you should write for an Android/iPhone app. Something different are the command for the build

$>flutter build web

and the command for local test.

$>flutter run -d chrom

Here I want just to underline how to invoke the Nimbella Python action we've seen at Phase 1 using the Dio dart library within a Flutter class.

. . .
  Future<String> save(String usercode, String item) async {
    var dio = Dio();
    dio.options.headers['content-Type'] = 'application/json';
    Response<String> response = await dio.post(
        NIM_SECRET_URL + '/api/item-save',
        data: {"user-code": usercode, "content": item});
    Map<String, dynamic> res = jsonDecode(response.data);
    res = res["response"];
    return res["result"] == "ok" ? "RES_OK" : "RES_NO_OK";
  }
 . . .

It's easy to both send POST HTTP requests and parse its json response.

Phase 4 (deploy Flutter web app on github pages)

All you need to deploy a web app to Github pages is reported here

https://pages.github.com/

In few words you need a Github account and you have to create a repositrory following a name convention like this:
"<your_account>.github.io"
and all html/js stuff you will push on it will reacheable at this link https://<your_account>.github.io/
really easy!

Conclusions

That's all! I hope that this post can help everyone wants to follow the same path I did to learn (very very basic level) both Flutter and Nimbella. To be honest, I already had a basic knowledge of Flutter before starting this journey; however now I'm sure that:

Flutter is a fantastic framework that let you write Mobile App, Web Apps and Desktop as well (even if not yet with a stable release) with only one language (Dart) end with a unique platform.
Nimbella is really a great FaaS alternative to question the hegemony of the great cloud serverless players as AWS, Azure and Google Cloud because is very effective and its learning curve is very smooth; I've not yet understood how much it is easy to integrate it with other Cloud solutions (It's something I need to study :-) :-) :-) ). I hope there will be available, as soon as possbile, a lot of connectors in order to be able to interact with other cloud PaaS.

DEV Community: rosidotidev

In-Depth Comparison: Workflow Control with LangGraph and CrewAI

Absolute Control Over Agent Steps: LangGraph vs. CrewAI

Example: The Java Verifier

1. CrewAI: Java Verifier with Flow

2. LangGraph: Java Verifier with Graph

Conclusion

Crewai

Spring.ai

crew

CrewAI meets RAG: built-in and custom solutions

Understanding RAG: The secret to accurate AI

RAG Ingestion Phase

RAG Retrieval Phase

Why RAG is a Game-Changer

CrewAI: Orchestrating Smart Agents for flexible RAG

Implementing RAG with CrewAI: Three Practical Approaches

Native RAG Tools

Knowledge for Document-Based RAG

Custom tool that uses Vector Search (FAISS in our case)

Real-World Example: Demonstrating RAG Flexibility with Multi-Crew Setup

Conclusion: Takeaways of the reading

Trading

Simplifying backlog management on Jira with CrewAI

Implementation overview

agents

tasks

tools

Conclusions

GenAI meets Jira: Transforming CSV Exports into Insights

Let's Start

The Main Script

Explanation

Key Components

Reading the CSV: df_manager.py

Creating the Agent: agent_manager.py

Building the Web Application: web_app.py

Conclusion

Just F*cking do it! Book takeaways

Takeaways

The Book

Flutter 2.0 meets Nimbella

The idea

Plan and Result

Phase 0 (Get a Nimbella free subscription)

Phase 1 (Python actions on Nimbella)

Phase 2 (Upgrade to Flutter 2.0 for web development)

Phase 3 (implement Flutter web app)

Phase 4 (deploy Flutter web app on github pages)

Conclusions

`agents`

`tasks`

`tools`

Reading the CSV: `df_manager.py`

Creating the Agent: `agent_manager.py`

Building the Web Application: `web_app.py`