Introducing the Agreement Engine

By Joshua Tan and Luke Miller

Agreements and contracts are everywhere, but they are built on layers and layers of legal and social institutions. Software is slowly entering into this stack. In this post, we introduce the Agreement Engine, an open-source software service for stitching together systems of modular agreement systems, as well as some of the social and legal theory on why and how agreements work.

Update: this post has been extended in an academic paper published in the MIT Computational Law Report.

Agreements are the building blocks of modern societies. Whenever you want to work with other people — whether it’s starting a business, building open-source software, or slaying a (virtual) dragon — you will need to first form an agreement with those people to communicate expectations, safeguard rights, and divvy up rewards. When we change the agreements that people can form, for example through policies that affect communication technology, social trust, or the rule of law, we change the kinds of economies and politics that people produce.

But what determines the agreements that people can form? Or, to put it another way: for a given kind of agreement (legal, informal, computational, etc.), how can we build systems for authoring and enforcing such agreements? Such systems range from a state’s business registration process, to the small claims court system, to the Ethereum smart contract system, to the guild systems of online games like World of Warcraft or EVE Online. In this article we’ll cover the art and science of how to build these systems as well as sticky questions about the user experience (UX) of legal contracts versus smart contracts versus informal agreements. This matters because:

• If you’re a lawyer, legal contract systems are important, but legal contract systems are evolving to become more computational.
• If you’re a blockchain enthusiast, smart contract systems are important, but the smart contract systems are evolving to become more “legal” — and not just because governments are getting involved.
• If you design or operate online platforms of any sort (blockchains, MMOs, and beyond), your platform’s virtual economy will never take off if your users can’t coordinate and collaborate with each other.
• If you’re a normal person, neither legal nor smart contract systems are particularly user-friendly or cheap. And that has significant consequences for a just internet.

At the end of this post, we’ll share a preview of Agreement Engine, a software service that converts any web resource into an enforceable contract, and place it within the larger project of building web-native “legal” systems. Agreement Engine is part of Metagov, a cross-platform toolkit for online governance.

What is an agreement, really?

What do the following have in common?

1. A signed rental contract
2. A one-line email: “cool, meet you at 9pm outside the bar”
3. A (multi-party) smart contract, e.g. this DAO
4. A bid on eBay
5. A gif of two men exchanging a knowing look

Figure 1. Walter and Jessie exchange a knowing look (from Breaking Bad).

Answer: they are all manifestations of mutual assent, a.k.a. agreements. Mutual assent is just a piece of jargon that means “we agree” — it’s an abstract relation or meeting of the minds between two or more subjects where the subjects share a common intention or a common belief. Agreements are manifestations of mutual assent, meaning that they bear witness to the claim that a common intention or belief exists. To put it another way: every agreement constitutes evidence of mutual assent.

Many agreements also incur obligations, where an obligation is an action that one has to do. These obligations usually come with mechanisms for enforcement, where enforcement is the act of compelling compliance with an obligation. For example: an email thread between two friends agreeing to meet at a bar (1) is explicit evidence of mutual assent and (2) creates a social obligation to meet at said bar where (3) the obligation to show up is enforced by an implied social norm: don’t break promises to friends or you’ll lose your friends and/or be reputed as a flake. A bid on eBay, on the other hand, (1) is evidence of the bidder’s agreement to buy the item at that price and (2) creates an obligation to pay the seller at that price if they win the auction where (3) that obligation is either enforced automatically through eBay’s escrow system or through eBay’s unpaid item policy.

Figure 2. A glossary of the many terms in this post.

Introducing the Agreement Engine

The (1)-(2)-(3) pattern of agreement-obligation-enforcement is extremely common in society and in the law. We call this pattern a contract system, and we call agreements that fit this pattern contracts. The Agreement Engine is a tool for building contract systems on the internet. For testing purposes, we’ve used Agreement Engine to build some actual contract systems (including the @AgreementEngine bot on Twitter) that end-users can use to produce contracts. [3]

As a tool for building contract systems, Agreement Engine is designed for two kinds of users: (1) platform operators that want to build up their communities and economies and (2) online communities that want a low-effort, minimal governance system that naturally evolves as the community grows.

Technically speaking, Agreement Engine is a software service that wraps a digital resource (usually text representing an agreement) and connects it to a governance service (usually an enforcement mechanism). We call these wrappers joint accounts, to distinguish them from agreements, and we call the process of wrapping an agreement with a joint account registration. Once wrapped or registered, a joint account can be validated and delivered to an enforcement mechanism through a process that we call authentication. [4]

To be clear, Agreement Engine itself is neither a system for authoring agreements nor a system for enforcing them. However, it has built-in interfaces with both authoring systems and enforcement systems (see Figure 3). In that sense, it serves a broadly similar role to both traditional legal notaries, which are trained to witness paper signatures for legal enforcement, as well as online services like DocuSign or HelloSign, which are designed to record digital signatures for legal enforcement. Unlike either legal notaries or digital signature software, which primarily take written or digital text and prepare the document for legal consumption, Agreement Engine is designed to take written or digital content of any sort and prepare that content for consumption by a range of online authorities including community administrators, digital juries, and automated platforms. In that sense, it is similar to other “web-native” arbitration services like Kleros, Aragon Agreements, or Celeste in that it is designed to operate independently of the traditional legal system. Unlike those services, however, it does not specify a deliberation mechanism for judging contract fulfillment or package an enforcement mechanism such as escrow. Agreement Engine is designed to be a lightweight, configurable component within a modular governance architecture.

Figure 3. Examples of four key processes in a contract system: authoring, registration, authentication, and enforcement. An authoring process allows end-users to write and negotiate contracts with each other. A registration process allows end-users to record their mutual assent, usually with some trusted entity. An authentication process is triggered when the record of mutual assent needs to be verified by an enforcement mechanism. Finally, an enforcement mechanism interprets the content of an authenticated agreement, often (but not always) with accompanying evidence, in order to enforce or compensate for any outstanding obligations.

Speaking of modular governance — Agreement Engine is a project of Metagov, which aims to provide governable wrappers for any digital resource, entity, or service, especially resources exposed through a web interface such as an API or URL. While we won’t go into the details, Agreement Engine is intended to serve the use-cases where the joint accounts represent agreements and contracts between a number of entities, while Metagov is intended to serve the use-cases where the joint accounts represent pre-existing communities such as a subreddit, a DAO, a Minecraft server, or all of Twitter.

Figure 4. Comparison of different registration services.

Enforcement through social capital

“[Capital] is a social relation of a certain kind. It is a triangulated relation. It never only involves the asset and the asset holder. It always involves this social resource that we call law, and the law works because it is backed by the enforcement powers of the state.” — Katharina Pistor, The Code of Capital

Here we outline a contract system, built using Agreement Engine, that uses an experimental enforcement mechanism called TSC, or “Twitter Social Capital”. You can try it out now by messaging @agreementengine on Twitter. TSC is a tokenized form of social capital. Each TSC token represents the ability to exert social work—i.e. to like or retweet something—within the confines of the Twitter platform. We built it on Twitter in order to capture some of the vibrant flows of social capital that already exist there. Using TSC, Twitter users can

1. hold each other accountable, e.g. “@agreementengine agreement 5 likes @lessig I promise to visit the next time I’m in Cambridge!”
2. send likes for whatever reason, e.g. “@agreementengine send 100 @RealAnnaWintour I have no taste, so I’ll let you decide what I like and don’t like”
3. make bets, e.g. “@agreementengine agreement 20 @JoeBiden I bet Lebron makes his next 10 free throws”
4. or skip TSC altogether and make another Twitter user in charge of the judging, e.g. “@agreementengine agreement @pizzahut, if you can get a large cheese pizza to 30 rock lobby in the next 10 minutes, I’ll pay your guy the pizza cost + $20. @dominos will judge”

While the TSC contract system is only one possible contract system that one can build with the Agreement Engine, we think it’s an interesting preview of the range and diversity of contract systems that are possible on the internet, as well as a great case study of the authoring → registration → authentication → enforcement process. Below, we go into the specifics of TSC’s design.

TSC has the following properties:

1. TSC can be minted by users
2. TSC can be burned and converted into social action (likes, retweets)
3. TSC can be transferred between users
4. TSC can be used as collateral in agreements

Broadly speaking, we built TSC (1) to see what a “Twitter-native” form of enforcement might look like, and (2) to have a testable, interactive hierarchy of enforcement, one that includes legal-, market-, norm-, and code-based mechanisms. This means that when someone breaks a contract,

1. The TSC protocol is fundamentally a piece of software, and thus the lowest level of enforcement exists in code. The protocol keeps track of and determines the quantity of TSC owned by each user. From a user’s perspective, the protocol’s actions are deterministic and infallible.
2. The next level of enforcement is the TSC market. As fundamental actions rely on minting, trading, and burning TSC, the ability to perform actions within the context of the Agreement Engine are regulated by the value of TSC, which is in return regulated by supply and demand in the market.
3. We’ve designed a basic legal enforcement system that regulates agreements made between users, and the reputation system that underlies social contract usage. Disputes are resolved by jurors employed by TSC.
4. Finally, while we can’t engineer precise social norms around agreements, we predict that they will play a high-level role in contract enforcement by discouraging users from going back on their promises.

More specifically, TSC is an attempt to create a non-monetary currency that can serve multiple use cases. It is an easy way to punish users or entities for breaking an agreement. By putting up TSC as collateral, more serious agreements can be made that have real consequences if they are broken. Creating an TSC ecosystem also allows for automated systems that can provide services, buy/sell, trade, etc. and accumulate their own balance. Within our systems users could be taxed and their TSC could be spent to promote the platform on Twitter or implement governance systems. You can read more about TSC’s design and our plans for a reputation and jury system in our public spec.

Figure 5. System diagram of the TSC enforcement mechanism.

Open questions

Right now, Agreement Engine registers and authenticates agreements on Twitter so that they can be enforced through TSC contracts. Here are some other contract systems that we would (eventually) like to add support for:

1. A Twitter agreement, enforced by staking one’s reputation on Reddit
2. A Markdown file with a code of conduct hosted on GitHub, enforced by a GitHub Group’s owner
3. A text contract published via Google Doc, enforced by a jury of Slack users
4. A smart contract not on Ethereum, enforced by placing tokens in escrow on Kleros
5. A grant agreement from one DAO to another DAO, enforced by a third DAO

We also note that while the intended use-case of the Agreement Engine is to connect an agreement with explicit enforcement mechanisms, agreements do not have to specify any enforcement mechanism. One can register a Twitter agreement without any enforcement mechanism, and this is perfectly okay — indeed, the lack of pre-specified enforcement can speak volumes about the intended nature of the agreement and the relationship between the two parties. In the future, we hope to build a few additional features in Agreement Engine specifically to support these informal agreements.

The team (meaning Josh, Luke, and some of the other folks at Metagov) will be working on v0.2 of Agreement Engine over the summer, including better tooling for TSC, better integration with Metagov itself, a new enforcement mechanism using Reddit reputation, and (maybe?) an Ethereum.world deployment.

Eventually, we hope that Agreement Engine will make it easier to build and deploy contract systems across a range of different platforms. But in building the first version of Agreement Engine, we’ve already learned that enforcement mechanisms are not as hot-swappable as we would like to think that they are. So one of the questions we’d like to address is how to make enforcement-swapping as fluid as possible.

Here are some other questions we’d like to engage with:

1. What kind of problems do agreements and contracts solve? Instead of building marginally better contracts and agreements, can we apply a little bit of design thinking and re-imagine new solutions to social coordination, collective action, and trust problems?
2. In a related vein: What kind of problems do registration and authentication processes solve?
3. How do agreements compose to form more complex agreements? If agreements are truly “building blocks”, then they should have some way of “snapping on” to each other. Yet when we look at the many kinds of different agreements (legal, social, computational, etc.), it seems clear that different kinds of agreements build on and connect to each other in very different ways.
4. Similarly: how do enforcement mechanisms compose with each other to form more complex enforcement systems?
5. Ultimately, is it possible to form a true community out of a decentralized network of small, freely-made agreements? In other words, is bottom-up, “emergent” governance possible in the digital world, or must we always be governed by rules and communities imposed from above?

We have a lot of work to do, but if you have comments on Agreement Engine, please let us know below! And if you’d like to get involved, feel free to hop on our GitHub; Agreement Engine (along with the rest of Metagov) is open-source, and we’d love to have you on board.

Acknowledgements

We would like to thank Nathan Schneider, Lawrence Lessig, Miriam Ashton, and James Duncan for helpful comments in the development of this project.

Endnotes

[1] Note, however, that not every agreement is definitive evidence of mutual assent.

[2] Informal agreements can include very explicit terms and consequences, and some are actually more diligently enforced than any formal contract, e.g. a loan shark’s “if you don’t pay me back, I’m going to beat you up”. The difference is that there is no formal institutional structure or “system” for enforcement.

[3] It’s important to understand the distinction between a contract and a contract system. Contracts are particular agreements between particular people, while contract systems describe all the infrastructure necessary to produce a large class of contracts. We emphasize contract systems in this article and in the design of Agreement Engine.

[4] This vocabulary should sound familiar. By design, wrapping an agreement is similar to how you register a (user) account on any website, and preparing an agreement for enforcement is similar to how you login to a website with a login name and password. The key difference is that, in Agreement Engine, the singular “you” is replaced with you, any other people named in the agreement, and the relationship between all of you as described in the agreement. As it turns out, this difference can make things very complicated.