[Agility] is a 'federated cloud computing platform' designed to improve business agility through a more flexible infrastructure approach. Federated, because Agility™ is constructed from IT resources that are assigned by autonomous, cooperating, business parties within and beyond the enterprise.

The description goes on to say that:

Whilst trust and power are real organizational barriers to resource sharing, Agility™ provides a controlled way for the enterprise to organically grow its 'internal cloud'. Resource owners retain control by attaching policy to the assigned resource which describes the conditions under which it can be shared by Agility™. Once assigned and subject to policy, Agility™ dynamically provisions the resource pool to meet the changing IT demands of the business.

As with some other Cloud-platforms, the services and tools needed to accomplish this provisioning can exit with existing infrastructural investments. However, ultimately Agility needs control over the whole Cloud if it is to deliver on the promised benefits:

Whilst Agility™ can be deployed onto existing infrastructure without compromising it, the power of Agility™ will be realized as IT resources are incrementally assigned under its control.

It would be good to compare and contrast this new platform with existing solutions, but it's obviously still early in its development. However, the updated white paper does give some clues:

Unlike other approaches, Agility does not force “big bang” changes onto the enterprise’s IT infrastructure and applications.

This initially seems at odds with the statements around needing full control, but there does seem to have been a lot of effort put into squaring that circle. In fact, according to the information available, Agility "does not require existing infrastructure to be restructured or changed in any way" and "does not require resources to be shared, except with the permission of the owner". It would seem that this non-invasive approach extends all the way to users, who do not even have to be aware of Agility when utilising services.

Services and resources are made available to Agility through the definition of policies, e.g., a policy that allows some of their resources to be made available to other users in particular circumstances, such as during critical times for the business when the rest of the infrastructure is overloaded. Unfortunately there's no obvious indication of how policies are defined within Agility, e.g., WS-Policy? In fact all relationships are represented as Service Agreements. Could this be a step towards embracing more SOA Governance approaches in Cloud computing in general?

Then they have a Virtual Deployment Description Language, which is a high-level language in which to describe services, along with the hardware and software resources they require, and the connections between them. Once again, this has parallels in some aspects of SOA Governance and service dependency graph work. But it appears to be a novel approach for Cloud-computing. If not then this may be a place where standardisation would help to reduce the vendor lock-in problem.

But given Arjuna's background, where does fault tolerance come in?

... dependability can be improved by supporting the dynamic redeployment of resources whenever failures are detected. After failure, as service requirements are decoupled from the IT infrastructure, Agility is able to identify alternative resources that could be used to satisfy the service requirements and then reconfigure the system to use those resources in order to ensure continued fulfillment of service requirements

There's no indication of whether Agility works with existing failure suspector mechanisms or uses its own. Without a more detailed architectural description it's not possible to say either way. But one things does seem certain: it looks like this time round transactions are not in the picture (unless they are a hidden part of the infrastructure.)