Posts Tagged ‘MarioFusco’
[VoxxedDaysTicino2026] Agentic AI Patterns
Lecturer
Kevin Dubois is a Senior Principal Developer Advocate at IBM, previously with Red Hat, focusing on Java, AI, and cloud-native development. As a Java Champion and Technical Lead for the CNCF Developer Experience Technical Advisory Group, Kevin authors content, speaks internationally, and contributes to open-source projects. Mario Fusco, co-presenter, is a Senior Principal Software Engineer at IBM (Red Hat), leading the Drools project. A Java Champion with expertise in functional programming and domain-specific languages, Mario coordinates the Milano Java User Group and frequently speaks on software engineering topics. Relevant links include Kevin’s LinkedIn profile (https://ch.linkedin.com/in/kevindubois), Mario’s LinkedIn profile (https://it.linkedin.com/in/mario-fusco-3467213), and Mario’s X account (https://x.com/mariofusco).
Abstract
This article investigates patterns in agentic AI systems as presented by Kevin Dubois and Mario Fusco, emphasizing orchestration of AI services for complex tasks. It delineates foundational components, workflow-based orchestration, autonomous agent models, and extensible planners. Through analysis of methodologies in LangChain4j with Quarkus, it elucidates contexts, implementations, and ramifications for building sophisticated AI applications.
Foundations of AI Services and Agentic Systems
Kevin and Mario initiate their discourse by establishing core elements of AI-infused applications, particularly within Java ecosystems using LangChain4j and Quarkus. An AI service fundamentally interfaces with a large language model (LLM) to process inputs and yield responses. However, effective integration demands more: precise prompting to elicit desired outputs, memory management to sustain conversational context, tool invocation for external actions, and data augmentation via retrieval-augmented generation (RAG).
Prompting emerges as pivotal; vague instructions yield suboptimal results, whereas structured prompts enhance accuracy. Memory, absent in standalone LLMs, requires client-side tracking—LangChain4j automates this, customizable via caching. Tools enable LLMs to perform actions like database queries or email dispatch, via function calling where LLMs request tool usage.
RAG integrates proprietary data: embeddings store vectorized information in databases like Pinecone, retrieved to enrich prompts. Moderation filters harmful content, ensuring ethical outputs.
Agentic systems extend this: agents, autonomous entities with goals, leverage these components. Patterns categorize into workflows (predefined paths) and autonomous agents (dynamic LLM-directed processes). Contexts include scenarios needing multi-step reasoning, like trip planning involving weather, flights, and accommodations.
Implications: These foundations enable modular, scalable AI, but demand careful design to mitigate errors like hallucinations.
Code illustrates basics:
@RegisterAiService
interface WeatherAgent {
String getWeather(String city);
}
This defines an AI service interfacing with an LLM for weather queries.
Workflow-Based Orchestration of Agents
Workflow patterns orchestrate agents through coded sequences, suitable for predictable tasks. Kevin and Mario detail sequential, parallel, conditional, and looping workflows in LangChain4j.
Sequential invokes agents in order: e.g., weather retrieval followed by outfit suggestion. Parallel executes concurrently, aggregating outputs—useful for independent subtasks like multi-city weather checks.
Conditional branches based on outputs: if weather is rainy, suggest indoor activities. Looping iterates until conditions met, like refining content via reviewer-critic cycles.
Methodology employs builders:
AgenticSystem system = AgenticSystem.builder()
.sequence(weatherAgent, outfitAgent)
.build();
Execution yields structured results, with event logs for monitoring.
Contexts: Workflows suit deterministic processes, reducing LLM variability. Implications: Enhance efficiency but limit adaptability; error handling via retries or prompt adjustments is crucial.
Autonomous and Dynamic Agent Orchestration
Autonomous patterns empower an LLM-orchestrator to dynamically select agents, ideal for unstructured tasks. The orchestrator evaluates inputs, plans invocations, and executes, adapting via reasoning.
Mario explains: Orchestrator prompts guide tool (agent) selection. Execution involves planning, tool calls, and result integration until resolution.
AgenticSystem system = AgenticSystem.builder()
.autonomous(orchestrator)
.agents(agent1, agent2)
.build();
Contexts: Handles ambiguity, like open-ended queries. Implications: Increases flexibility but risks infinite loops or off-track reasoning; human-in-the-loop mitigates via approvals.
Multimodal extensions process PDFs or generate images, expanding applicability.
Extensible Planners for Custom Agentic Patterns
To accommodate diverse needs, Mario introduces pluggable planners, abstracting orchestration. This service provider interface (SPI) allows custom implementations, like goal-oriented patterns using A* search.
Planners initialize with agents, determining next actions: invoke agents (sequentially/parallel) or conclude. Existing patterns refactor atop this.
Goal-oriented example: Define prerequisites and goals; algorithm generates invocation graphs.
Planner customPlanner = new GoalOrientedPlanner(agents);
AgenticSystem system = AgenticSystem.builder()
.planner(() -> customPlanner)
.build();
Hybridization combines patterns, e.g., goal-oriented with loops for refinement.
Contexts: Custom scenarios like adaptive learning systems. Implications: Fosters innovation, but requires algorithmic expertise; promotes modularity in AI design.
In summary, Kevin and Mario’s patterns advance agentic AI, blending structure with dynamism for robust applications.
Links:
[DevoxxBE2025] Behavioral Software Engineering
Lecturer
Mario Fusco is a Senior Principal Software Engineer at Red Hat, where he leads the Drools project, a business rules management system, and contributes to initiatives like LangChain4j. As a Java Champion and open-source advocate, he co-authored “Java 8 in Action” with Raoul-Gabriel Urma and Alan Mycroft, published by Manning. Mario frequently speaks at conferences on topics ranging from functional programming to domain-specific languages.
Abstract
This examination draws parallels between behavioral economics and software engineering, highlighting cognitive biases that distort rational decision-making in technical contexts. It elucidates key heuristics identified by economists like Daniel Kahneman and Amos Tversky, situating them within engineering practices such as benchmarking, tool selection, and architectural choices. Through illustrative examples of performance evaluation flaws and hype-driven adoptions, the narrative scrutinizes methodological influences on project outcomes. Ramifications for collaborative dynamics, innovation barriers, and professional development are explored, proposing mindfulness as a countermeasure to enhance engineering efficacy.
Foundations of Behavioral Economics and Rationality Myths
Classical economic models presupposed fully efficient markets populated by perfectly logical agents, often termed Homo Economicus, who maximize utility through impeccable reasoning. However, pioneering work by psychologists Daniel Kahneman and Amos Tversky in the late 1970s challenged this paradigm, demonstrating that human judgment is riddled with systematic errors. Their prospect theory, for instance, revealed how individuals weigh losses more heavily than equivalent gains, leading to irrational risk aversion or seeking behaviors. This laid the groundwork for behavioral economics, which integrates psychological insights into economic analysis to explain deviations from predicted rational conduct.
In software engineering, a parallel illusion persists: the notion of the “Engeen,” an idealized practitioner who approaches problems with unerring logic and objectivity. Yet, engineers are susceptible to the same mental shortcuts that Kahneman and Tversky cataloged. These heuristics, evolved for quick survival decisions in ancestral environments, often mislead in modern technical scenarios. For example, the anchoring effect—where initial information disproportionately influences subsequent judgments—can skew performance assessments. An engineer might fixate on a preliminary benchmark result, overlooking confounding variables like hardware variability or suboptimal test conditions.
The availability bias compounds this, prioritizing readily recalled information over comprehensive data. If recent experiences involve a particular technology failing, an engineer might unduly favor alternatives, even if statistical evidence suggests otherwise. Contextualized within the rapid evolution of software tools, these biases amplify during hype cycles, where media amplification creates illusory consensus. Implications extend to resource allocation: projects may pursue fashionable solutions, diverting efforts from proven, albeit less glamorous, approaches.
Heuristics in Performance Evaluation and Tool Adoption
Performance benchmarking exemplifies how cognitive shortcuts undermine objective analysis. The availability heuristic leads engineers to overemphasize memorable failures, such as a vivid recollection of a slow database query, while discounting broader datasets. This can result in premature optimizations or misguided architectural pivots. Similarly, anchoring occurs when initial metrics set unrealistic expectations; a prototype’s speed on high-end hardware might bias perceptions of production viability.
Tool adoption is equally fraught. The pro-innovation bias fosters an uncritical embrace of novel technologies, often without rigorous evaluation. Engineers might adopt container orchestration systems like Kubernetes for simple applications, incurring unnecessary complexity. The bandwagon effect reinforces this, as perceived peer adoption creates social proof, echoing Tversky’s work on conformity under uncertainty.
The not-invented-here syndrome further distorts choices, prompting reinvention of wheels due to overconfidence in proprietary solutions. Framing effects alter problem-solving: the same requirement, phrased differently—e.g., “build a scalable service” versus “optimize for cost”—yields divergent designs. Examples from practice include teams favoring microservices for “scalability” when monolithic structures suffice, driven by availability of success stories from tech giants.
Analysis reveals these heuristics degrade quality: biased evaluations lead to inefficient code, while hype-driven adoptions inflate maintenance costs. Implications urge structured methodologies, such as A/B testing or peer reviews, to counteract intuitive pitfalls.
Biases in Collaborative and Organizational Contexts
Team interactions amplify individual biases, creating collective delusions. The curse of knowledge hinders communication: experts assume shared understanding, leading to ambiguous requirements or overlooked edge cases. Hyperbolic discounting prioritizes immediate deliverables over long-term maintainability, accruing technical debt.
Organizational politics exacerbate these: non-technical leaders impose decisions, as in mandating unproven tools based on superficial appeal. Sunk cost fallacy sustains failing projects, ignoring opportunity costs. Dunning-Kruger effect, where incompetence breeds overconfidence, manifests in unqualified critiques of sound engineering.
Confirmation bias selectively affirms preconceptions, dismissing contradictory evidence. In code reviews, this might involve defending flawed implementations by highlighting partial successes. Contextualized within agile methodologies, these biases undermine iterative improvements, fostering resistance to refactoring.
Implications for dynamics: eroded trust hampers collaboration, reducing innovation. Analysis suggests diverse teams dilute biases, as varied perspectives challenge assumptions.
Strategies to Mitigate Biases in Engineering Practices
Mitigation begins with awareness: educating on Kahneman’s System 1 (intuitive) versus System 2 (deliberative) thinking encourages reflective pauses. Structured decision frameworks, like weighted scoring for tool selection, counteract anchoring and availability.
For performance, blind testing—evaluating without preconceptions—promotes objectivity. Debiasing techniques, such as devil’s advocacy, challenge bandwagon tendencies. Organizational interventions include bias training and diverse hiring to foster balanced views.
In practice, adopting evidence-based approaches—rigorous benchmarking protocols—enhances outcomes. Implications: mindful engineering boosts efficiency, reducing rework. Future research could quantify bias impacts via metrics like defect rates.
In essence, recognizing human frailties transforms engineering from intuitive art to disciplined science, yielding superior software.
Links:
- Lecture video: https://www.youtube.com/watch?v=Aa2Zn8WFJrI
- Mario Fusco on LinkedIn: https://www.linkedin.com/in/mariofusco/
- Mario Fusco on Twitter/X: https://twitter.com/mariofusco
- Red Hat website: https://www.redhat.com/