From GO-BPMN to Agentic AI: Why Goal-Oriented Modeling Matters Again
How lessons from Tropos, Gaia, and AUML help modern Java architects model adaptive, goal-driven, and agentic AI systems with Quarkus.
Fifteen years ago, I came across something unusual in the world of business process modeling: GO-BPMN (Goal-Oriented Business Process Modeling). It wasn’t just another extension of BPMN. It elevated goals and agents to first-class modeling concepts.
Where BPMN focused on how tasks were executed, GO-BPMN focused on why they mattered and who (agents) could act autonomously to achieve them.
This approach was later commercialized by Whitestein as the Living Systems Process Suite (LSPS). The promise was bold: adaptive processes that could flexibly reorganize themselves around business goals.
The reality? It was too early. Enterprises weren’t ready to embrace adaptive, agentic workflows. AI wasn’t mature enough, and runtime platforms were designed for deterministic, centralized processes. The ideas were brilliant, but the tools of the time fell short.
Today, that has changed.
Why Agent-Based Systems Are Different
Agent-based systems differ fundamentally from workflow automation:
Goals, not just tasks. Work is defined by outcomes, not linear activity chains.
Capabilities over control. Agents expose what they can do; orchestration emerges dynamically.
Protocols matter. Interactions, negotiations, and escalations are central.
Adaptation is expected. Context, risk, and data shifts should trigger changes in strategy.
Traditional notations like BPMN and UML are limited here. They describe static flows, but agents behave adaptively and autonomously. GO-BPMN was an early attempt to fix this gap.
Modern Approaches Emerging
Today, a mix of software engineering practices, enterprise modeling languages, and AI orchestration frameworks are converging on the same principles as GO-BPMN back in the days: Processes must be adaptive, agent-driven, and guided by goals. Several approaches are shaping this new landscape:
Multi-Agent Methodologies
Academic methods like Tropos, Gaia (PDF), and AUML modeled roles, goals, and interaction protocols. While they stayed niche at the time, they map cleanly to multi-agent AI orchestration we see today.
Domain-Driven Design + Event Storming
Event Storming provides a business-friendly way to capture events, outcomes, and responsibilities. Applied to agentic systems:
Agents = bounded contexts with autonomy.
Goals = desired outcomes.
Protocols = contracts and message flows.
Executable Specifications
Frameworks like LangChain4j and LangGraph define agents, tools, and interaction rules in YAML/JSON configs. These are both documentation and runnable specifications, closing the gap between design and execution.
Enterprise Architecture Views
ArchiMate Motivation views for goals and outcomes.
C4 model adapted to agents and their boundaries.
SysML v2 for system-of-systems modeling.
All share a trajectory: move from static diagrams to living, executable artifacts.
A Meta-Methodology for Modeling Modern Agentic Systems
The agent community gave us Tropos, Gaia, and AUML more than 20 years ago. Each had a unique lens:
Tropos: goals and requirements (the why).
Gaia: roles and organizational rules (the who/what).
AUML: interactions and protocols (the how).
On their own, each was incomplete. But together, they provide a powerful template for agentic AI systems where large language models, microservices, and guardrails collaborate.
Tropos
Focus: Goal-oriented agent modeling throughout the entire software development lifecycle.
Key Ideas:
Uses i* (i-star) framework for requirements modeling.
Models stakeholders as actors with goals, plans, resources, and dependencies.
Supports both early requirements (understanding organizational goals) and late requirements (system-to-be specification).
Extends into architectural design and detailed design, ensuring traceability from goals to implementation.
Strength: Strong emphasis on why the system exists (goals, rationale). Good for aligning IT with business objectives.
Limitation: Heavyweight modeling, requires deep training, can be abstract for developers used to concrete implementation detail.
Gaia
Focus: Methodology for analyzing and designing multi-agent systems.
Key Ideas:
Defines roles and interactions as primary abstractions.
Two main phases: Analysis (identify roles, responsibilities, interactions) and Design (define agent types, services, organizational rules).
Emphasizes organization structure: how agents combine into a society with norms and rules.
Uses safety and liveness properties to reason about correctness.
Strength: Clear framework for designing complex agent societies, especially with multiple interacting agents.
Limitation: Less emphasis on early requirements/goals (compared to Tropos); focuses more on how agents interact rather than why.
AUML (Agent UML)
Focus: Extending UML to model agent-specific concepts and interactions.
Key Ideas:
Builds on familiar UML notation (class, sequence, state diagrams) with agent extensions.
Introduces concepts like roles, protocols, beliefs, desires, and intentions (BDI).
Useful for modeling agent communication protocols (e.g., FIPA-compliant).
Keeps strong alignment with object-oriented design, making it more accessible to traditional software engineers.
Strength: Familiar notation lowers adoption barrier; directly supports interaction modeling.
Limitation: More of a notation than a complete methodology; doesn’t guide full development lifecycle.
Similarities
All three recognize that agents are not just objects; they have autonomy, goals, and social interactions.
Each introduces abstractions beyond traditional software engineering (e.g., roles, protocols, goals, dependencies).
All aim to provide better modeling of complex, distributed, adaptive systems compared to object-oriented methods.
Major Differences
The three methodologies differ most in their orientation. Tropos is fundamentally goal- and requirements-driven. It emphasizes the why of a system. Why it exists, what organizational goals it serves, and how those goals can be decomposed into dependencies and responsibilities for agents. Gaia, in contrast, is role- and organization-driven. It focuses more on the who and what of a multi-agent system: which roles are needed, what responsibilities they carry, and how agents are structured into an organization with rules and norms. AUML takes yet another perspective, being interaction- and protocol-driven. It looks closely at the how of agent communication, documenting conversations, negotiations, and message exchanges using extended UML notation.
The scope of each method also diverges. Tropos covers the full software development lifecycle, starting with early requirements and extending all the way to design. Gaia is narrower, focusing on the analysis and design phases of multi-agent systems rather than requirements capture. AUML is even more focused: it does not try to guide the entire development lifecycle but instead provides a notation layer for modeling agent concepts and interactions.
Their strengths reflect these orientations. Tropos excels at aligning IT with business strategy because it ties requirements directly to goals and rationales. Gaia’s strength lies in structuring multi-agent organizations, making it well suited for systems where coordination and rules are critical. AUML is strongest as a pragmatic bridge for developers. By extending familiar UML diagrams, it lowers the adoption barrier and gives engineers a clear way to represent agent protocols and conversations without learning an entirely new modeling language.
Each approach also has clear weaknesses. Tropos can be heavy and abstract, requiring significant modeling effort and specialized knowledge. Gaia pays less attention to early requirements and business alignment, focusing instead on structural concerns. AUML, while accessible, is not a complete methodology — it is essentially a notation system that must be combined with other approaches to cover requirements, design, and implementation.
Finally, their best-fit scenarios highlight the complementarity. Tropos is best when the priority is to ensure a system aligns with business goals and provides traceability from intent to implementation. Gaia is most effective for designing agent societies with multiple interacting roles and organizational rules. AUML is most useful when there is a need to document protocols and interactions, especially in contexts where developers are already comfortable with UML.
Tropos is best when you need to model why the system exists and ensure alignment with business strategy.
Gaia excels when building societies of agents with complex organizational rules and responsibilities.
AUML provides a pragmatic bridge for developers, helping document agent protocols in a way that feels familiar.
Together, they represent three complementary lenses:
Tropos = strategy and goals,
Gaia = structure and roles,
AUML = interaction and communication.
For modern agentic AI systems (e.g., LangGraph4j or multi-agent LLM frameworks):
Tropos’ goal-orientation maps to high-level intent specifications.
Gaia’s roles/organization resemble multi-agent orchestration topologies (hierarchical, democratic, etc.).
AUML’s protocol modeling aligns with tool calls, MCP interfaces, and messaging contracts.
Take the best from each world and approach this step by step.
Step 1: Capture Goals and Intent (Tropos Lens)
Start with goals, dependencies, and rationales. In modern terms:
Business goals → “reduce average support response time.”
System goals → “answer FAQs with 90% accuracy.”
Agent goals → “Compliance Guard Agent ensures PII is masked.”
In practice:
Use ArchiMate Motivation view or Event Storming to capture goals.
In LangGraph4j, represent these as graph entry nodes or goal conditions.
Traceability matters: every agent and tool must link back to a goal.
Step 2: Define Roles and Organization (Gaia Lens)
Agents don’t exist in isolation. They form roles and organizational structures.
Roles: LLM Support Agent, Escalation Agent, Compliance Guard.
Responsibilities: What services/capabilities each role provides.
Organizational rules: “Escalation Agent may only hand off to Human Agent if compliance check passes.”
In practice:
Document roles in a C4 Container diagram, each container = agent role.
In LangGraph4j, encode this as subgraphs or orchestrators (e.g., hierarchical vs. peer-to-peer topologies).
Define safety/liveness properties as tests or guardrail policies.
Step 3: Model Protocols and Interactions (AUML Lens)
Agents achieve goals through conversations. AUML gave us notations for agent interactions, now directly relevant for AI agent orchestration.
Message protocols: query → validation → escalation.
Negotiations: if multiple agents propose solutions, who decides?
Compliance constraints: insert guardrails into every protocol.
In practice:
Document as Mermaid sequence diagrams (or AUML-style sequence charts).
In LangGraph4j, model protocols as edges in the graph between nodes. Each edge can have conditions (confidence threshold, compliance result).
In Quarkus LangChain4j, map interactions to tool definitions and REST endpoints.
Step 4: Governance and Documentation
Blend the three perspectives into a governable artifact:
Tropos goals → documented in YAML as graph entry points.
Gaia roles → represented as agent/service classes in Quarkus.
AUML protocols → documented as interaction graphs and enforced with guardrails.
goals:
- name: Improve Responsiveness
success_metric: first_response_time < 10s
roles:
- name: LLM Support Agent
capabilities: [faq_lookup, ticket_creator]
depends_on: [Compliance Guard Agent]
- name: Compliance Guard Agent
capabilities: [pii_detection, policy_enforcement]
policies: [GDPR, PCI-DSS]
protocols:
- name: Support Escalation
flow:
- from: LLM Support Agent
to: Compliance Guard Agent
condition: "confidence < 0.7"
- from: Compliance Guard Agent
to: Escalation Agent
- from: Escalation Agent
to: Human Agent
This file is both documentation and execution config, closing the loop.
A Unified Blueprint
Tropos gives us intent → goals anchor everything.
Gaia gives us structure → roles and organizational rules keep the system coherent.
AUML gives us interaction clarity → protocols define the choreography.
For Java architects, the opportunity is to combine these into executable designs:
Use LangGraph4j for orchestration graphs.
Use Quarkus LangChain4j for tool integration, guardrails, and endpoints.
Use Mermaid and YAML for documentation that doubles as runtime specs.
This is the natural evolution of GO-BPMN’s vision: goal-driven, adaptive, and agentic systems that enterprises can both understand and run.
Outlook: What Java Architects Should Do Now
The ideas behind GO-BPMN are no longer academic curiosities. They are becoming practical necessities in modern agent-based AI systems.
Recent work like Anthropic’s contextual retrieval and LangGraph demonstrates that:
Goals are once again the organizing principle.
Agents (human and AI) operate as peers in adaptive workflows.
Executable specs are the bridge between design and runtime.
For Java architects, the call to action is clear:
Experiment with LangGraph4j. It brings LangGraph’s declarative multi-agent workflows to the JVM, integrated with Quarkus LangChain4j.
Model goals, not just flows. Start describing systems in terms of desired outcomes and adaptive agent roles.
Adopt executable documentation. Use YAML/JSON specs that double as runtime configs and architectural blueprints.
Design for governance. Build compliance, observability, and escalation into your models from the start.
The lesson from GO-BPMN is simple: processes should adapt around goals, not lock into tasks. Today, with Java, Quarkus, and agent orchestration frameworks, you can finally make that vision real.