Methodology · Multi-Agent Designprovenverified

AOSE Lifecycle Methodology (Prometheus-style)

also known as agent-oriented software engineering lifecycle, Prometheus methodology

Applies to: multi-agent-system

Tags: aosebdilifecycleprometheustraceability

This is a full, step-by-step process for building a multi-agent system, adapted from Prometheus and related methods. It runs in phases: gather requirements, write the system spec, design the architecture, design each agent in detail, build it, test it, then maintain it. Each phase produces a named document that feeds the next. The agents are described in terms of what they believe, what they want, and what they plan to do (the formal name is BDI, for Belief-Desire-Intention). This is the heavyweight opposite of 'wire up an agent loop and iterate'. People have used it on long-lived multi-agent systems for decades. It trades speed for a clear trail from each goal to the agent that ends up running in production.

Methodology process overview

Intent. Take a multi-agent system from rough requirements to a maintained production deployment along a fully traceable path, with named documents at each phase that outlast staff turnover.

When to apply. Use this for a long-lived multi-agent system where the trail from goal to agent matters more than a fast first demo. That covers safety-critical agents, regulated domains, multi-team systems where the contracts between agents must be auditable, and research deployments meant to outlast the original team. Don't apply it for a throwaway prototype, a single agent loop, or a system whose requirements you expect to rewrite every week. The overhead is wasted there. One exception: even small projects can borrow a single artefact, such as a goal hierarchy or a role model, without taking on the whole process.

Inputs

  • Stakeholder goals — What the people who rely on the system need, stated informally. What it should achieve, who depends on it, and what success looks like.
  • Domain knowledge — The subject-matter expertise needed to model the world the agents work in. The things in it, how it changes, the constraints, and what the agents can sense.
  • Available agent technology — What the build will run on. The agent platform, the way agents communicate, the agent toolkit, and the runtime environment.

Outputs

  • System specification — The formal statement of what the system must do. It holds the goal hierarchy, the scenarios, the actions the agents can take, and what they can sense.
  • Architectural design — The agent types, who plays which role, how the agents talk to each other, and what data they share.
  • Detailed agent designs — For each agent: what it can do, its plans, what it believes about the world, and how it handles events.
  • Implemented multi-agent system — Running code that turns the architecture into reality on the chosen agent platform.
  • Test artefacts and maintenance plan — Tests for single agents and for how they work together, plus a written procedure for changing the system over time.

Steps (7)

  1. Requirements analysis

    Capture stakeholder goals, scenarios, and what the environment is like. Produce a goal hierarchy. Break big goals into sub-goals, all the way down to leaves you can actually act on.

  2. System specification

    Pin down the edge of the system. What the agents can sense, what they can do, and which scenarios tie goals to sequences of actions. Produce a system overview diagram.

  3. Architectural design

    Group the goals into agent types. Assign roles. Spell out how the agents talk to each other. Identify the shared data and say where it lives. Produce a map of which agents know each other, plus the protocols.

  4. Detailed agent design

    For each agent type, design what it can do, its plans, its beliefs, and how it handles events. A plan is a recipe for reaching a goal in a given situation. Beliefs are the agent's picture of the world.

  5. Implementation

    Turn the detailed designs into running code on the chosen agent platform. Map plans to the platform's plan bodies, beliefs to belief-base entries, and protocols to message handlers.

  6. Testing

    Test single plans and abilities on their own. Test how the agents interact against the protocols. Where formal methods fit, model-check key properties, such as whether a protocol always makes progress or whether shared data stays safe.

  7. Maintenance

    When requirements change, walk the change back up the chain: requirement, then goal, then role, then agent, then plan. Update the documents at each step. The trail is the asset. Quick patches that skip the chain destroy it.

Framework-specific instructions

Pick a framework and generate a framework-targeted rewrite of this methodology's steps.

Choose framework

AI-generated for Agent Development Kit (ADK) (Google) — verify against official docs.

Principles

  • Every phase produces a named document. A phase with no document is a wish, not a result.
  • The main deliverable is the trail from a stakeholder goal to the plan that runs in production.
  • What each agent believes, wants, and plans to do are first-class parts of the design, not implementation details.
  • Maintenance walks the chain. Patching code without updating the documents upstream destroys the very trail you paid for.

Known failure modes (3)

Related patterns (4)

Sources (2)

Provenance

  • Added to catalog:
  • Last updated:
  • Verification status: verified