The Genesis of a Pattern Language for Agent-based Enterprise Systems

Paul R. Taylor, Peter Evans-Greenwood, James Odell.

Agentis International,
2/33 Lincoln Square South, Carlton, Victoria, Australia.
26/405 Lexington Avenue, New York, NY, USA.
{ptaylor|pevansg|jodell}@agentis.net

Abstract
Patterns have recognised utility in software engineering
design and development processes.
The body of
knowledge of design and development of agent-based
systems is now sufficiently mature to be usefully
expressed as a pattern language. The essential elements
of agent-based decompositionautonomous agents,
relationships between agents, and organisational
structureslend themselves to a pattern-based
description. This paper describes an initiative currently
underway at Agentis Software to mine, document and
evolve a complete pattern language for agent-based
systems. These patterns define recurring agent-based
structures for both individual agents and multi-agent
system architectures. This paper discusses the software
engineering motivations for making this investment in
patterns by describing the strategic and pragmatic
motivations, the pattern mining process, how the
patterns are used in the design of agent-based solution
architectures, and our experiences in using and evolving
the pattern language.

Introduction

A process for mining, reviewing and disseminating

agent-based design patterns has been operating at Agentis
Software for over a year. The patterns that have resulted
embody significant knowledge of the design of agentbased software architectures, individual agents, and
agent-oriented coding idioms and mechanisms within
agents. The pattern languagethough still relatively
immatureis changing the way agent systems are being
designed. We believe that its use will increase software
design and code quality and introduce a degree of
repeatability in the delivery of agent-based systems, and
we suggest that patterns represent a highly viable and

1/6

pragmatic way of introducing sound software engineering

principles into the development of enterprise agent
systems.
The concepts underlying software patterns need little
introduction, but the motivations for choosing to write
patterns (as opposed to using existing patterns) and the
justification of the return on this investment are worthy of
discussion. Creation of a pattern language is not
something to be taken lightlyproposers of such an
initiative must have a mandate and clear support from
their community of practice. For a toolkit vendor (such
as Agentis) this support must include a strategic
commitment to open up the pattern language and its
associated code resources to the wider Agentis
development community, and to provide a guarantee of
platform support for the patterns.

1.1

Motivations for creating a pattern

language

Patterns express recurring software designs using a

standard literary template that serves to externalise the
motivations, tradeoffs and final resolutions of the expert
designer. Patterns mature, merge, and diverge as richer
experience illuminates more agent-oriented solutions and
as more patterns are documented. In time, a repository of
patterns becomes a design vocabularya languagein
which novices and experts can converse, short-circuiting
the monotony of traditional models of mentoring and
craftsmanship, and ensuring higher quality designs get
done faster and without unnecessary re-invention. As
individual patterns mature, their interdependence
increases, and the overall strength of a pattern language
emerges.
Architecting well-designed, extensible, scalable
agent-based solutions is a job for a technology expert.
Agentis product offering is typical of productivity
platforms in that it incorporates quality documentation,
training and other collateral. However, these are not
enough to engender expertise.

Figure 1: The role of patterns in the knowledge spiral.

The scarcity of agent solution design expertise

presents a classic knowledge management challenge
how should the essential expertise necessary to
successfully design and develop agent-based systems and
solutions be explicated and shared? The very nature of
this expertise works against us to begin with.
The best (and most experienced) architects employ
their combined knowledge of agent concepts, design
expertise and platform awareness both explicitly and
tacitly. They are no different to conventional software
architects, or architects of built-world structures, in the
ways they reuse certain template solutions and building
blocksand particular arrangements of these building
blocksin the conceptualisation of their designs.
Architectural theorist Christopher Alexander calls these
blocks and template structures patterns, and regards all
of the great architects of history as having internalised
pattern languages of our own, from which we arrange
our personal spaces and form our own designs. When a
person is faced with an act of design, writes Alexander
[1] what he does is governed entirely by the pattern
language which he has in his mind at the moment
(p.203).
To become an effective agent solution designer, an
experienced solution architect must learn how to use
goal-directed BDI agent technology appropriately. The
recipes for how best to do this are only just emerging
from the Agentis development community. At this stage
of the technologys adoption, it is crucial that ways of
sharing these private rules of thumb of the most
experienced designers are found, surfaced, expressed in a
suitable form, reviewed for soundness, and shared via a
suitable medium. Figure 1 from May and Taylors
description of patterns as a knowledge management
process [4] illustrates how explication of tacit knowledge
(as patterns) ultimately enriches the practitioners
explicit, and then over time, tacit knowledge, in a
transparent cycle of learning.

2/6

1.2

Patterns and risk mitigation

There are other pragmatic motivations for an

investment in an agent pattern language.
Before
organisations adopt a new enterprise software
technology, every possible impediment must be
eliminated. To this end, Agentis has invested in a
number of bridges between established enterprise
software engineering approaches and agent technology.
One is an import capability in the Agentis product that
allows representations of UML business models to be
imported into Agentis agent modelling environment.
Another is a small set of extensions to UML to support
the translation of roles into role-based agent modules.
We regard the agent pattern language as another bridge.
Enterprise developers require access to a body of patterns
to develop confidence in the new development approach.
Patterns, as proven best practice solutions, mitigate
project architecture and design risk.
The pattern
language, along with a supporting software component
repository, integration with the methodology, training,
experience reports and case studies are offered as a
complete solution offering. It is also critically important
that ownership of the pattern language sit with the
community of practice rather then with a vendor.

1.3 Patterns and agent-based decomposition

Agent technology provides an alternative basis for
solution decomposition. When experienced agent-based
system architects design, they apply this decomposition
method to create viable solution models comprised of
agents and roles. Anthropomorphic approaches such as
these appear to have application in complex, enterprise
systems, as evidenced by the growing body of case
studies [2].
In making a case for agent-oriented software
engineering, Jennings [3] claims the essential
characteristics of agent-based systems are i) modelling
with agents, interactions, and organizations; ii)

decomposing the problem into multiple autonomous

agents that can act and interact in flexible ways to achieve
their objectives, and iii) using explicit structures,
protocols and mechanisms to manage the complex and
changing web of organizational relationships that exist
among the agents. Designing in this fashion is clearly not
trivialin simple terms, the design of multi-agent
systems parallels the design of object-oriented systems
but adds a new degree of dynamism to the dimensions of
individual agent behaviours and the inter-agent
relationships.
Most decisionsincluding the exact
configuration of the collaborating entitiesare deferred
until runtime, which leads to new levels of nondeterminism. The designers method and personal design
processes do not yield to nave stories that may have
worked with object-oriented decompositions. Neither are
divide-and-conquer-based iterative decomposition
techniques sufficiently rich to address these
characteristics of agent-based solutions. While the
emerging plethora of agent methodologies are now
beyond their infancy, verification depends upon a large
base of reported, verifiable experience.
As this will take some years to materialize, patterns
provide a sound theory and practical methodology to
iteratively capture, refine and validate these structures.
As well, patterns are essentially about structure.
Experience from object-oriented systems development
serves to validate the use of patterns in documenting
agent code-level structures, structures of inter-agent
relationships, and agent organisations. We have tried to
document patterns for our agent platform in all three
spaces.

Figure 2: A category map of agent patterns.

Our Approach

The Agentis pattern language was created by an

immersive activity to mine and author the most

3/6

fundamental architectural, design and code patterns,

which resulted in a core of 17 patterns. To structure the
effort in selecting candidate patterns, the agent solution
space was categorised on the basis of conventional
enterprise architecture abstraction layers.

2.1 Pattern categories

The pattern language is structured around three
categories: architectural patterns, which recommend
structural solutions to problems at the level of system and
agent architectures; design patterns, which solve common
design problems within an agent, and tactical patterns,
which offer pragmatic solutions to everyday problems
when working with the platform.
These categories can be thought of as horizontal
layers, with tactical patterns at the bottom (since these
patterns extend the agent development platform), agent
design patterns, and agent-architectural patterns at the top
(since they address the most abstract system-level
structures).
Within these layers, particularly the
architecture and design layers, a further classification into
business process, functional design, and data and
integration patterns can be made (Figure 2). This grid
serves two purposes. Firstly, it provides a way of
locating and relating a candidate pattern to the existing
solution design space.
Secondly, it orientates the
designer in locating a pattern needed to solve a particular
problem. The layering should not be taken to imply that
the patterns in the Agent Architectural layer are
abstractthey are just as concrete in their problem and
solution definitions as are the tactical patternsthe
distinction is purely that
they address the kinds of
problems encountered when
designing
agent-based
systems compared with
designing modules, goal
hierarchies, goals or plans.
Tactical patterns are
similar to Java or C++
coding idioms and are
heavily dependent on the
realisation of core BDI
concepts in the agentmodelling platform. Most
of these patterns describe
best practice approaches to
achieving some desirable
characteristic in an agent. Examples include idioms to
implement abstraction, encapsulation, and data
homogenisation or manipulation. Tactical patterns are
supported with a reference implementation (code
sample), which can be cloned and reused. Because this
category of patterns is closest to the agent development

platform, it immediately began to attract local workarounds for unimplemented platform feature requests.
The resulting patterns provided valuable planning and
prioritisation input to the products roadmap. Over time,
we expect some of these patterns to be subsumed into the
Agentis product.
Agent design patterns sit at the next higher level of
abstraction and describe agent-based realisations of many
of the building blocks of enterprise applicationssmart
caches, filters, intelligent data structures, for example.
These are accompanied by a reference implementation in
the patterns repository that an agent developer can copy
and easily reuse. The developer typically designs with
these patterns and merges the reference implementations
in appropriate ways.
Patterns of agent-oriented system architecture sit at
the next level of abstraction in the solution space. These
include agent-based realisations of system-level
constructs that are applicable both within individual
agents (roles, layers and facades, for example) and
between agents in a multi-agent system (observers and
brokers, for example).
The pattern-mining effort does not stop there. As
experience in developing agent-based solutions
accumulates in particular markets or business domains,
recurring solution structures are identified, and clusters of
patterns are mined within specific solution domains.
Work has commenced on workflow, real time business
exception handling, and rule interpretation solution
domains, as well as in vertical markets such as insurance
underwriting. These pattern clusters, and their template
code modules, approach the utility of small, selfcontained frameworks, which designers combine and
extend to design agent architectures and assemble agent
solutions.

2.2

Sample patterns

Two short-form samples (Figure 3) from the language

illustrate the approach to individual patterns. Note that
these are greatly summarisedthe actual patterns include
full implementation details and discussions of
considerations and optimisations (they run to 6 and 11
pages respectively).
The RULE COMPOSER pattern makes many
assumptions about the best way to model business rules.
By recommending a rule equals goal approach, the
patterns solution emphasises rule encapsulation, and
opens the door to a broader notion of rule as goal-directed
rule. The patterns final solution captures the preferred
option. When less experienced developers implement a
RULE COMPOSER, the pattern guides them away from
these pitfalls. Individual patterns live or die on their
usefulnessif the patterns solution is impractical,
unworkable, or involves some form of unacceptable

4/6

compromise, it will not be used. Patterns, to survive into

maturity, have to be firmly grounded in practical
experience.
Another sample pattern (Figure 3, right) from the
language illustrates the architectural layer. The DECISION
TREE is a framework that executes within an agent to
control a question-and-answer dialogue with the
applications user. As the user responds to questions
(prompts), their answers are passed to the DECISION TREE
for interpretation and navigation.
The DECISION TREE selects the appropriate sub-tree
based on the users response, and also optionally invokes
application-specific behaviour in the agent at each node
of the tree by delegating the users responses to an
action goal. Inside this goal, any application-specific
behaviours can be implemented to invoke goal-directed
processing at each node in the tree. For example, an
agent could accumulate the users answers, perform
partial processing on them, or retrieve information from
external systems to inform the user about the current state
of the dialogue. Traversal of the DECISION TREE
completes when it reaches a leaf node, at which time the
final action goal can complete any calculations and return
the results.
DECISION TREES can be nested, composed, or
assembled dynamically to support arbitrarily complex
dialogues. It is typical of the patterns found in the Agent
Architectural dimension of the pattern language in that it
represents an architectural response to a class of recurring
agent solutions. Its sample implementation in the pattern
repository includes Agentis agent modules, Java source,
and sample database schema. With repeated reuse, this
architectural pattern will mature into a solution
component, as unit test harnesses, test data, generalisation
for different databases and deployment options, and code
to support configuration are all added.

2.3

Designing with patterns

The agent pattern language puts new nouns in the

agent solution designers vocabulary. It is not difficult to
anticipate how knowledge of several dozen such patterns
changes the way an architect thinks about, discusses, and
documents solutions.
The highest level of
decomposition, into agents, roles and relationship
structures, can be expressed with patterns of multi-agent
organisations. There is scope to enrich our pattern
language in this dimension, mainly because there are
fewer opportunities to repeatedly discover and validate
these patterns in the domain of enterprise application
development. Even within solutions that require only
relatively static organisations of agents, we have valuable
experience in using loosely coupled multi-agent
structures. Within individual agents, the language is
richest.

Name: RULE COMPOSER

Name: DECISION TREE

Context: You are implementing goal-based data or

form validation within an agent.

Context: You are implementing an agent-based

self-service web application.

Problem: You have lots of interdependent validation

rules that must be applied during a business
process.

Problem: You want to guide the user through a

sequence of decisions, but you want the agent to
control the dialogue.

Forces:
There are many validation, scheduling, sequencing
and selection scenarios where you need to apply a
number of business rules against a business data
structure.
A naive approach might be to combine the
individual validation rules into a single logical
expression. This approach restricts the ways you
can implement the rules to those expressions and
creates a maintenance problem because of the
complexity of the composed usage rules.
A more flexible approach is to think of each
individual business rule as a goal. Rules can run
the full range of complexity from a simple
expression implemented in a usage rule for one of
the goals plans, to a complex decision making
process implemented with multiple plans and subgoals. It also strongly encapsulates the
implementation of the rule, so that its evolution and
change over time will not impact other parts of the
agent.
The validation is then done by composing the
individual business rules (goals) under a common
validation goal, which provides simple rule
composition.

Forces:
In some web applications, navigation is dependent
upon what interactions or data have been provided
previously. As more information is collected from
the user, the application makes informed decisions
about narrowing or customising the presentation of
options. In an agent-based system, you want a
user interface agent controlling the user dialogue.
You need to represent a hierarchy of dependent
navigation or business rules, so that the agent can
control the dialog with the user and resolve to a set
of recommendations, options, or product offerings,
or calculation of results.

Solution: Encapsulate a number of (possibly

interdependent) business validation rules behind a
single validation goal (the RULE COMPOSER goal),
which manages the interdependencies, ensures
that all the appropriate validation rules are
executed regardless of their outcomes, and reports
on the overall result.

Solution: Use a DECISION TREE (a tree with decision

and action metadata on each node) that represents
all possible dialog paths and corresponding action
sequences.
Each node in the tree represents a question
presented to the usera decision point. Each time
the user answers a question, the DECISION TREE
collects the supplied answer(s), delegates the
users responses to an application-specific action,
and selects the appropriate sub-tree, progressing
toward the leaf node.
When the leaf node is reached, the DECISION TREE
invokes whatever final calculations the agent
needs to perform on the set of attributes collected
during the traversal, and returns the result.
The user can then re-visit any of the nodes in the
current tree, initiate a new dialogue with a different
instance of the same DECISION TREE (in parallel, if
this makes sense), or initiate a dialogue with
another supported DECISION TREE.

<< implementation details omitted >>

<< implementation details omitted >>

Consequences:
<< note on a disjunctive variant >>
<< note on an audit trail >>
<< note on the definition of rule>>

Consequences: I
<< note on asymmetric trees >>
<< note on instantiating multiple trees >>
<< note on data-driven trees >>
<< note on cycles >>
<< note on localisation considerations >>

Figure 3: Some indicative (short-form) patterns from the language.

2.4

A pattern lifecycle model

Architects and developers use existing patterns and

components during development of an agent-based

5/6

solution. In her work, the reflective architect will likely

uncover potentially useful new patterns. Candidate
patterns should not be written up immediatelythe idea
needs to be floated for a period, so that others in the

community can review it, and so that its proposer can rethink and re-conceptualise it. Patlets exist to support
this early phase of a patterns existence.
A patlet is a cut-down pattern that states a name, the
problem, some (optional) bullet-pointed forces, and the
solution. It can be as simple or as detailed as the author
desires. The patlet sits on a shared portal and collects
comments. It takes three seconders from the community
to justify creation of a pattern from a patlet. When this
happens, the patlet (with the review input from its
seconders) is formally prototyped using the agent
platform and written up using the standard pattern
template. The new pattern is published and indexed but it
stays in Draft state.
The new draft pattern now surfaces in the pattern
repository. Users and reviewers accumulate comments
and feedback, which will quickly indicate its usefulness
or otherwise. When three instances of the patterns use
have been recorded, it transitions from Draft to Final
state. A patterns state is therefore the best indication of
its maturity.
A pattern in Final state may ultimately be retired, or
merged with other patterns, as the agent platform
changes. Patlets and patterns are never explicitly deleted,
as the life history of a pattern traces the progression of
design thinking about a particular problem and its
solutions.

3 Brief Assessment
The pattern language has found an enthusiastic
audience amongst Agentis consultants, partners, and
clients. Patterns are being used, sample implementations
reused, and feedback is accumulating on a shared services
portal. Judging from feedback, the decision to aim the
pattern language at enterprise Java developers has been
vindicatedso much so, that the pattern language is
being used to support technical pre-sales activities, a
benefit not anticipated.
In general, we have found that the patterns are larger
(in terms of the number of participating elements, the
description, and the reference implementation) and more
complex than traditional object-oriented patterns.
DECISION TREE is a good example of this. This may be
due to our definition of patternan OO traditionalist, for
example, might argue that DECISION TREE is conceptually
a component rather than a pattern. Our definition is
driven by achieving productivity through efficient reuse
of the reference implementation by project team
members.
Integration of the language with the Agentis product
roadmap is tight, and as new features are planned for
release, patterns must be updated. Pattern use is now a
valuable input to roadmap planning.

6/6

Conclusion

A process of pattern mining, review, use and

evolution has been established at Agentis Software,
specifically to explicate agent-based system design and
implementation knowledge. The motivations for this
effort include the acceleration of skilling agent
technology solution architects and risk mitigation on the
part of technology adopters. Patterns are regarded as an
excellent medium for representing agent-based designs,
due to the inherent structural basis of agentbased
decomposition.
The Agentis pattern language is organised around
three abstraction layers and three functional layers.
Individual patterns within each grid square include a
comprehensive sample implementation, and repository
artefacts to facilitate immediate reuse and customisation.
Designing with agent-based patterns is essentially
familiar to object-oriented design pattern users, but
involves added design dimensions of runtime structure
negotiation and adaptability, for which some early
patterns are emerging.
A healthy pattern authoring and reviewing process
reflects the health of a software engineering community
of practice. Ultimately, the target of any pattern initiative
should equally be the well being and longevity of the
pattern mining process as well as the language itself. The
activities of proposing, authoring, reviewing and
publishing patterns need to become embedded in the
communitys culture, such that designers are able to pick
up (and cut back) their involvement in pattern
development as their interests or other workloads allow.

References

[1] Alexander, Christopher, 1979. The Timeless Way of

Building. New York, Oxford University Press.
[2] Taylor, Paul; Evans-Greenwood, Peter; Odell, James.
Agents in the Enterprise. Industry Track Proceedings,
Australian Software Engineering Conference (ASWEC 2005)
29th March - 1st April 2005, Brisbane, Australia.
[3] Jennings, Nicholas R.; Bussmann, Stefan. Agent-Based
Control Systems: Why Are They Suited To Engineering
Complex Systems?. IEEE Control Systems Magazine, June
2003.
[4] May, Daniel; Taylor, Paul. 2003. Patterns and Knowledge
Management. Communications of the ACM, July 2003, Vol.
46 No 7, p94-99.