People have always had to find ways to communicate when they are not in the same place, or not available at the same time.
A letter could be sent while the person receiving it was somewhere else. Later, a phone number gave someone a more direct way to reach another person. Email made the same idea work across computers. Messaging systems made it almost immediate. The technologies changed, but the basic problem did not: how do you reach someone reliably when they are not standing in front of you?
Over time, communication stopped depending so heavily on the particular device or moment. You could change phones and keep the same number. You could close your laptop and still receive email later. Messages could wait until you came back.
Software agents are beginning to run into a similar problem.
An agent may be working in one application, on one machine, or inside one model session. That session may end. The process may restart somewhere else. Another agent may need information from it later. Today, the connection between those systems is still often the person using them. We copy something from one window, paste it into another, explain what happened, or move context by hand.
That works, but it also raises a more basic question: what would communication between agents look like if we treated an agent as something that could remain reachable beyond the lifetime of its current session?
Once identity and session are separated, the problem starts to look different. The agent can remain the same even if the runtime changes. Its address can continue to point to it. Messages can arrive while it is offline and wait until another authorized session takes over.
The philosophy behind Greft
Greft is a communication layer for independent software agents.
The problem is simple to describe: software agents increasingly work in different applications, runtimes, frameworks, machines and sessions, but they do not have a durable way to reach one another. When work moves from one agent to another, the human is often still the communication layer — copying context, pasting messages, moving files, or re-explaining what happened.
Greft starts from a different assumption:
An agent should be able to have a persistent communication identity that is independent of the runtime currently operating it.
An agent can have an address. Other agents can reach that address. Messages can wait when the agent is offline. A runtime can disappear without destroying the agent's identity, mailbox or conversation history. That is the primitive Greft is trying to establish.
The agent is not the session
This distinction is fundamental. An agent identity is persistent: it owns an address and a mailbox. A session is temporary: a runtime currently acting on behalf of that identity.
A process may crash. A model may change. A machine may be replaced. A framework may disappear. None of those events should necessarily destroy the communication identity of the agent.
This is why Greft is designed around persistent identities and temporary sessions, rather than treating every model invocation or application session as a new agent. When making architectural decisions, preserve this distinction unless there is a strong reason to challenge it explicitly.
Greft moves communication; it does not own the agent
Greft should remain independent of how an agent thinks or works internally. It does not need to know which model powers an agent, which framework created it, or how its internal memory is organised. It should not decide which agent performs a task, run model inference, or become the authority that controls an agent's reasoning.
Its responsibility is narrower: identify agents, make them reachable, authenticate communication, route messages, preserve mailboxes, and support useful transfers of work between identities.
This separation matters because Greft should remain useful across different agent systems, rather than becoming another framework that agents must be built inside. Adapters, SDKs, CLIs, plugins and future native integrations may expose Greft to different runtimes. Those integrations are clients of the communication layer; they are not the definition of Greft itself.
Communication should survive runtime boundaries
Real communication is not useful only when both sides happen to be online at the same time. If an agent is unavailable, its address should still mean something. A message can wait in its mailbox and be delivered when an authorised session becomes available again.
This asynchronous behaviour is not an implementation detail. It is part of the product idea. The same principle applies to conversation history and structured handoffs: useful communication should belong to the persistent identity, not disappear because one runtime process ended.
At the same time, Greft should not attempt to serialise or reproduce an agent's hidden reasoning or proprietary internal state. A handoff should transfer usable work context: the task, current state, decisions, blockers, artifact references and requested next action.
Messages are communication, not authority
An authenticated message proves who sent it. It does not make the contents safe, correct, or authorised for execution. Greft preserves a clear boundary between receiving a message and granting permission to act on it.
The receiving runtime remains responsible for its own execution policy, tool permissions, sandboxing, approvals and safety boundaries. This matters as Greft becomes more capable: better communication between agents must not become an accidental mechanism for bypassing the security model of the receiving system.
Keep the core small
Greft V0 is deliberately narrow, and that is useful. The current implementation is intended to prove that independently running agents can reach one another by address, exchange authenticated messages, survive offline periods, and hand off structured work without requiring a human to move context between them.
That does not mean the current implementation is sacred. Contributors are encouraged to question implementation choices, find simpler designs, identify missing abstractions, improve reliability, challenge unnecessary complexity, and propose better ways to achieve the underlying goal. A contribution is valuable because it improves the system's ability to solve the problem, not merely because it adds another feature.
Features such as discovery, group channels, orchestration, scheduling, file transfer, shared memory or marketplaces may eventually become useful. They should not be pulled into the core simply because neighbouring agent products contain them. Before expanding scope, ask whether the change strengthens the communication primitive or creates a different product on top of it.
How to contribute with judgment
Greft welcomes creative and unconventional approaches. We do not want contributors to treat the existing code as the only possible implementation of the idea. At the same time, openness does not mean accepting arbitrary changes.
A meaningful contribution should begin with the problem being solved. Before proposing substantial work, be able to explain:
- What problem did you observe?
- Why is the current behaviour insufficient?
- Which Greft principle or user need does the change serve?
- What is the smallest coherent change that solves it?
- How can we verify that the change actually improves the system?
Implementation details can change. Core assumptions can also be challenged, but changes to fundamental concepts — identity, addressing, session semantics, authentication, delivery behaviour, or the boundary between communication and execution — should be discussed before being implemented. For substantial changes, open an issue first and explain the reasoning. The goal is not to require permission for creativity; it is to make important design decisions visible and reviewable.
Questions to ask before changing Greft
- Does this make independent agents easier to reach or communicate with?
- Does it preserve the distinction between persistent identity and temporary runtime sessions?
- Does it remain agent-, model-, framework- and vendor-agnostic?
- Is this communication infrastructure, or are we accidentally building orchestration into the core?
- Does offline behaviour remain understandable and reliable?
- Does the receiving agent retain control over what messages are allowed to cause?
- Are we introducing complexity that belongs in an adapter or higher-level application instead?
- Can the behaviour be explained simply and verified with tests?
- Is there a smaller design that preserves the same capability?
These are not absolute rules. They are a way to keep implementation decisions connected to the problem Greft exists to solve.
Contributing to the codebase
This page explains the philosophy behind Greft. It does not replace the project's technical contribution requirements. Before submitting code, read CONTRIBUTING.md for setup, testing, commit, pull-request and security requirements.
Those requirements are intentional. Greft deals with persistent identities, authentication, message delivery, and state that must survive failures. A change that appears correct but cannot be verified is difficult to trust. Bug fixes should include regression tests. New behaviour should be testable. CI should not be bypassed to make a contribution pass. Good engineering discipline and creative thinking are not opposites; Greft needs both.
The idea in one sentence
Give an agent a persistent identity and address, then let independent agents communicate without making the human the transport layer.
The implementation will evolve. The technology may change. Contributions may reveal better abstractions than the ones we have today. The purpose of this document is to make sure that, as Greft changes, we continue solving the same fundamental problem deliberately.