# Agent Spaces
## Holonic Structure of Agent Spaces
Agent Spaces provide a way to group related agents and also provide the means through which they can interact.
{% hint style="info" %}
Def: **An *****Agent*** ***Space***** consists of a collection of agents as well as the medium through which they interact via discovery, communication and resource flows.**
{% endhint %}
The following diagram shows an example of an *agent space* consisting of three member agents. The green arrows represent resource flows between agents as a result of *service invocation*s. To keep this diagram from being too busy, other elements of services (offers, agreements, implementations, and usages) are implied but not shown.
The *agent space* has its own ***containing membrane*** that separates the *inside* of the *agent space* from the *outside* of the *agent space*. The *agent space* also has its own ***memetic signature*** that specifies (among other things) the values exhibited and inhibited by that *agent space* as well as the rules for membership of that space. Generally, these rules are based on some degree of alignment between the memetic signatures of the agent space and the memetic signatures of the agents belonging to that space (as depicted by the purple dotted lines in the diagram). It is useful to think of the containing membrane as *semi-permeable* -- only agents that meet the criteria spelled out in the rules of membership for the agent space are admitted *inside* the agent space.
An *Agent Space* can itself act as an *Agent*. Consider, for example, ***Corner Market*** -- a for-profit business organization. The *person agents* that have an *employed-by* or *contracted-by* relationship to the *Corner Market* can be thought of agents *inside* the *Corner Market's agent space*. Likewise the *compute server agents* *owned-by* the *Corner Market* are also part of its agent space. The *Corner Market* may offer *catering services* to other individuals and organizations. These customer agents lie outside the *Corner Market's agent space.* When its customers contract for catering services, their contract is with the *Corner Market* -- not the individual agents that work for the *Corner Market*. In fact, filing *Letters of Incorporation* with some government jurisdiction (itself an Agent Space) establishes the *Corner Market* as a separate legal entity. Its bylaws form part of the *Corner Market's* memetic signature.
The similarity of the diagrams for *an I-Space* and an *Agent Space* is not coincidental. In fact,
{% hint style="info" %}
Def: An ***I-Space*** is the ***view*** of an *Agent Space* from the perspective of the containing agent.
{% endhint %}
{% hint style="info" %}
Def: A ***We-Space*** is a ***view*** of an *Agent Space* from the perspective of the members of that *Agent Space*
{% endhint %}
The *I-Space* view focuses on the internal composition of an agent. The *We-Space* view focuses on the interactions between agents. An agent has only a *single* I-Space but can participate in *multiple* We-Spaces.The difference in perspective between *I-Space* and *We-Space* illustrates the ***holonic structure*** of the MAP. Thus, as we can see in the following diagram, an agent is a ***holon.***
The *person* (whole) includes of a set of *computing node agents* (e.g., their smart phone, laptop, desktop, holoport, tablet, etc.) and, at the same time, may also part of an *Organization*. The *Organization Agent* (whole) includes a set of *Person Agents* and, at the same time, is part of a larger (multi-organizational) *Enterprise Agent*.
Thus, agents can be composed into hierarchies of agents, referred to as ***agent holarchies***. However, unlike conventional ways of depicting such hierarchies (e.g., the classic "org chart", with people at the bottom of the chart and the organization at the top), the MAP places each agent at the center of its own holarchy.
The implications are profound. ***In the MAP, I am the center of the universe. And so are you!***
## Agents Spaces Encapsulate Data and Service Implementations
Agent Space membranes also serve to encapsulate data. Thus, *my data* is accessible only within *my I-Space*. For example, as a human being, my *I-Space* is a container for:
* *my memetic signature*: my private values, beliefs, aspirations, assumptions about what is, etc.
* *my agents*: for example, my phone, my desktop, my laptop, my phone, my HoloPort as well as the *offers*, *agreements,* and *resource flows* through which the members of my *I-Space* interact
* *my resources* (a.k.a., my assets): for example, artistic expressions (journal entries, works in progress, etc.), my personal health record (PHR) and more
Such data encapsulation is in direct support of the[Core Principles of the MAP](/map-book/core-principles-of-the-map.md#primacy-of-the-individual) and [Core Principles of the MAP](/map-book/core-principles-of-the-map.md#individual-sovereignty) principles of the MAP and represents a radical inversion of the conventional data ownership relationship (where data is owned by the provider of the application through which it is managed).
As noted in the [Foundations section](/map-book/map-foundations.md), MAP *Services* consist of an ***offer***, an ***implementation,*** zero or more ***agreements (accepted offers)*** and zero or more ***events***. The *implementation* of a service belongs to the *I-Space* of the offering agent -- i.e., it is encapsulated within that agent's *I-Space* and is not visible to other agents.
To offer the service, the offering agent can place the *Service Offer* in any of the *We-Spaces* to which it belongs. This allows the service provider to control the visibility of their service offerings, since only agents belonging to the *We-Space* containing the offer can see and accept that offer.
*We-Spaces* come in a wide range of types and sizes. A *We-Space* can represent everything from an intimate partnership (2 agents), to a family, an extended family, clan, community, tribe, organization, parties to a contractual agreement, registered voters within a jurisdiction, citizens of a nation, all human inhabitants on earth (7.8B and counting), the subset of those people that have internet access (estimated to be 4.66B in 2021), and many, many more.
To gain broad visibilty, a *Service Offer* should be placed in large *We-Spaces*. However, for a variety of reasons, I may wish to limit the visibility of the offer. These reasons include:
* *privacy concerns* -- I may not want everyone to know what services I am offering
* *lead qualification* *concerns* -- to avoid wasting my resources on non-productive interactions, I may want only those agents having a reasonably high probability of accepting my offer to see my offer,
* *service lifecycle concerns* (I may want to restrict the early "beta" release of an offer to a smaller population to keep the support level manageable).
* etc.
Some services may require information about or from the Service Requester in order to deliver the offered service. This data sharing arrangement is formally defined as part of the memetic signature of the *Service Offers* placed within that *We-Space*. These signatures spell out what information is required in order to deliver the specified service as well as constraints on the use and further shareablity of that data.
In choosing to accept a *Service Offer*, the service requester is deciding whether the value being delivered by the offered service is worth revealing the requested personal information. A salient factor is the degree to which the service requester trusts the service provider to use and protect any supplied information appropriately.
As group sizes grow, our capacity to remember and keep track of individuals is strained. In a small group, it is harder to hide untrustworthy actions. Robin Dunbar has famously proposed that there may be a cognitive limit on the number of meaningful and stable relationships a person can have at any one time. The so-called Dunbar Number places this limit at about 150 people. More recently, Dunbar has proposed that there may actually be multiple "dunbar numbers" -- that certain agent counts offer more stable groups than others and, remarkably, that these different sizes exhibit a scaling factor of three ([Friends: Understanding the Power of our Most Important Relationships](https://www.amazon.com/Friends-Robin-Dunbar/dp/1408711737)). These *dunbar rings* are depicted in the following figure.
Each band in the above diagram represents a stable group size. Whether or not Dunbar's theory regarding these stable group sizes is correct remains to be seen. Interestingly, it may be that once the MAP is sufficiently adopted (i.e., once a large number of self-organizing We-Spaces have been created), MAP data on We-Space agent counts may, itself, provide a rich dataset to confirm or refute Dunbar's theory. Regardless, one need not accept Dunbar's theory to believe in the basic principle illustrated in the above diagram -- that there tends to be an inverse relationship between the size of a We-Space and the degree to which agents within that space trust each other.
When an offer is accepted, an ***agreement*** is created within a *We-Space* containing (at least) the *Service Providing Agent* and the *Service Requesting Agent*. Note that this *We-Space* need not be (and often is not) the same as the *We-Space* containing the offer. This is illustrated in the following diagram.
In this example, a Service Providing Agent (say, a healthcare provider) is placing its offer of diagnostic and therapeutic services to everyone on the public internet (high reach/low trust). But should an individual (Service Requesting Agent) accept the offer, the fact that they have reached an agreement and any data or events ensuing from the services delivered per that agreement are only visible within a dedicated *We-Space* consisting solely of the Service Provider and the Service Requester (low reach/high trust).
## Standard Information Access Agreements (SIAA)
We expect that *standard information access agreement* (SIAA) types will be defined within a MAP *Meme-Space* that are inspired by and perhaps patterned after the [Creative Commons license types](https://creativecommons.org/licenses/).
Creative Commons licenses are defined according to a 3-level architecture: *legal*, *human-readable*, *software-readable*. The ***legal description*** of the license is written by and for lawyers and provides the legally enforceable representation of the agreement. The ***human-readable** descriptio*n is intended to be easily understood by humans so that they have a clear sense of their rights and responsibilities under the agreement. The ***software-readable*** description is intended to be understood and acted upon by software agents and to leverage ***cryptographically secured protocols*** as described in the following section.
Because of the MAP's self-describing foundations, the *software-readable* descriptions within MAP *service offers* can reference *type-descriptors* to precisely describe the objects and properties which are both consumed and produced by that service.
[JLINC](https://www.jlinc.com) provides one example of an information sharing agreement protocol that demonstrates how cryptographic techniques can be used to support reliable and secure service invocations. The choice of protocol is just one aspect of a Service Offer's *memetic signature*. The MAP allows different protocols to be registered within a *MAP Meme-Space* and selected for inclusion in any given *service offer.* This approach supports the *reliability* that stems from using proven prototcols, while also allowing the flexibility to adopt newer protocols as they evolve over time.
## Cryptographically Secured Service Invocations
**\**
### Levels of MAP Agent Holarchy
The definition of Agent adopted by the MAP encompasses a very broad range of scale and complexity. As illustrated in the following diagram, this definition encompasses the *physical* (quarks, atoms, molecules, planets, galaxies), the *biological* (cells, mitochondria, organs, plants, insects, fungi, humans, etc.) and the *memetic* (software containers, bots, computing nodes, organizations, enterprises and economies).
As a practical matter, however, the explicit focus of the MAP is at the scale of ***Computing Node*** and above. This section provides a deeper dive into these levels of the *MAP Agent Holarchy*. At each level, both the individual *I-Space* view and collective *We-Space* view are described.
**Copyright (c) 2022, this book is offered to the world under Creative Commons license** [**CC BY-NC-SA 4.0**](https://creativecommons.org/licenses/by-nc-sa/4.0/)
\ [Interledger Protocol](https://interledger.org/rfcs/0001-interledger-architecture/) in the service flow -- it handles monetary flows that are independent of current (connectors perform currency exchange operations)>
\
\
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://evomimic.gitbook.io/map-book/map-foundations/agent-spaces.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.