To achieve its vision, ARGUGRID is developing novel technology components, as well as extending existing ones. These include:

• Semantic workflow authoring via the InforSense KDE workflow system,
• MARGO and CaSAPI argumentation engines developed by University of Pisa and Imperial College London,
• the GOLEM multi-agent platform by Royal Holloway, University of London, and
• PLATON P2P platform by ICCS, National Technical University of Athens in Greece.

In addition, the platform makes use of the GRIA distributed middleware system.

ARGUGRID Big Picture - Click to start the animation

Within ARGUGRID, agents are associated with both service requesters and service providers. The operation of the platform, from the point of view of service requestors, can briefly be explained as follows:

1. A user develops an abstract workflow reflecting his/her requirements using the KDE.
2. The abstract workflow is then communicated to the GOLEM agent that reasons about services and makes decisions, aiding the refinement process of the abstract workflow.
3. The reasoning capabilities of the GOLEM agent are based on using the MARGO argumentation engine for decision-making, which in turn uses the CaSAPI general-purpose argumentation engine.
4. A GOLEM agent can negotiate with other GOLEM agents to form a Virtual Organisation (VO) whose purpose is to find a concrete workflow whose execution will satisfy the application requirements, as stated in the abstract workflow.
5. In order to discover an appropriate GOLEM agent or a GRIA Grid service, GOLEM agents are given the capability to use the P2P platform, linking all available GOLEM agents and GRIA services in a virtual registry that can be queried.
6. GOLEM agents can query the KDE system about SLA templates, needed for creating a concrete workflow that satifies user preferences.
7. The KDE, by accesing GRIA nodes, can retrieve information about SLA's.
8. Having carried out its mission, the GOLEM agent representing the user (i.e. the initial agent that received the abstract workflow from the KDE) will return to the KDE the concrete workflow, constituted of a set of GRIA services to be executed in a certain manner/sequence.
9. The KDE shows the suggested workflow to the user. If the user rejects the suggestion, a new workflow would be created.
10. The KDE executes and monitors the resulting workflow. Details about execution and the final results are presented to the user.