Hauddy and the Right to Act

The agents could do the work. I was still carrying it between them.

I kept rebuilding integrations, writing Markdown handoffs, and moving context from one tool to the next. Each connection seemed small enough to improvise. Together they became a second job attached to the first: deciding what the next agent needed to know, putting it somewhere it could read, and carrying its questions back. To avoid leaving something out, I shared too much. Tokens went into retelling things the next agent did not need, and each handoff inherited a little more of the mess.

A Markdown file can hold a careful account of what happened. It cannot ask the follow-up question. For that, someone has to make the return trip.

I started building Hauddy because I wanted to stop being that someone. Hauddy is an open-source alpha that lets AI agents exchange messages and files across tools, with live calls between compatible agents. An agent, in this sense, is software that can take steps and use tools on your behalf. One researches a problem. Another changes the code. Hauddy gives them identities, nicknames, and a contact book so that the research can reach the coding agent, the question can travel back, and I can inspect the conversation.

The first ambition is as ordinary as that: make a useful connection once and keep using it.

Consider the difference it could make to a handoff. The research agent sends a brief. The coding agent discovers that a recommendation depends on an assumption the brief does not explain, so it asks. The answer returns to the place where the work is happening. The person can still decide whether the recommendation is any good, without also acting as the delivery mechanism for every clarification.

That exchange does not automatically make context smaller or better. Agents can be verbose correspondents too. But it gives us a place to improve the handoff itself, instead of rebuilding the means of handing it over every time.

There is a working version of the connection already. The recorded demonstration shows a file passing from ChatGPT to Claude Code and a reply coming back. You can start with two local agents without a Hauddy account. The hosted network, including access for hosted assistants, requires an invitation during alpha. Hauddy brokers messages and stores their history; the payloads are not end-to-end encrypted. It is early software with visible limits, and the local setup guide is the place to begin.

Once the connection works, another question becomes hard to avoid. What happens to it when you change the software on either end?

---

We tend to speak about an AI product as though it were one thing. From the user’s chair, it often is: a window, a conversation, a place to ask for work. Underneath that experience are several choices that need not have the same answer.

There is the model, which generates responses and proposes actions. There is the harness, the software around the model that manages the session, assembles context, exposes tools, and runs the work. Then there are the tools and applications the agent reaches into: a search service, a code repository, an inbox, a calendar. A company can package several of these together so neatly that the seams disappear. That can be a very good product.

The seams still matter.

Suppose you like one company’s interface, another company’s model, and a set of applications you already use. Or suppose the model that serves you best this month is no longer the right one next month. Changing that choice should not require rebuilding every connection around it. Your preferred place to talk to an agent should not, by itself, decide where that agent is allowed to work.

We may get an “Apple of harnesses”: one company whose polished, integrated experience becomes the place where most consumers encounter agents. People might choose it for perfectly understandable reasons. A coherent interface saves effort. A system that works without assembly has real value. A dominant harness could earn its position by making something people prefer to use.

We may also get a much more varied world, with different harnesses for different kinds of work and no single front door that everyone walks through. I do not think the architecture should depend on guessing which future wins.

In either case, I want to keep the parts replaceable. Different model providers, different harness providers, different tools, different applications. Choose them together when that is convenient. Change one when there is a reason to. A person should be able to enjoy an integrated experience without making every other choice permanent.

A person should be able to enjoy an integrated experience without making every other choice permanent.

This is what I mean by Hauddy being harness agnostic. The connections should be useful across the environments in which agents run. Hauddy should be an independent tool those environments can use, with an open implementation and interfaces other people can build against. Today’s alpha connects supported clients; compatibility with every harness is an ambition, not an existing fact.

The concern becomes sharper when the connections carry more than messages. If one interface also becomes the only place where an agent’s identity, context, and permissions make sense, leaving it means rebuilding much more than a conversation. The convenience of arriving becomes the cost of leaving.

This is the same question The Reducing Valve keeps returning to from other directions: how much of the instrument acting for you do you actually control? Here, control includes the ability to change a part without having to start your working life over around it.

---

Follow the brief a little further. The coding agent has read it and needs to consult a project document before preparing its reply. Which document may it read? Does permission to receive the brief include permission to browse the whole folder? If it changes harnesses, who checks that permission then?

These are questions about context as much as identity. Giving an agent a name makes it reachable. Connecting that identity to a grant makes it possible to say something more useful: this agent may retrieve these materials for this piece of work, until this time. The service holding the material must check the grant before releasing it.

That is the direction I want to explore beyond messaging. Instead of sending the entire history just in case, we could give an identified agent a limited way to ask for the context it needs. More information would require more authority. The handoff would have a boundary that could be inspected, rather than a growing pile of material whose original reason for inclusion has been forgotten.

It would still require care. Access can be withdrawn; information already disclosed cannot be made unread. And moving to another harness should never silently expand a grant. A new environment must establish that it is entitled to use the identity and permissions it presents. Portability is useful when the limits travel too.

Now imagine the reply leaving the project as an email. It comes from a familiar account, contains the document you expected, and suggests a next step. You learn that an agent sent it. Perhaps its owner authorized exactly that. Perhaps the agent had only been asked to prepare a draft.

The address looks the same in both cases.

Existing applications already authenticate accounts and authorize access. What I want to keep visible is the relationship inside this particular action: which agent acted, which account it represented, and what that account allowed it to do. The distinction is established in identity systems. OAuth’s token-exchange standard describes delegation in terms that keep the actor distinct from the party it represents. There is good infrastructure to build on.

Think of the agent carrying a passport, a mandate, and a receipt. The passport establishes an identity and an attested relationship to an account. The mandate says what that identity may access or do. The receipt records the request and its outcome. With those distinctions intact, a receiver could tell the difference between an identifiable agent, an authorized action, and an action that actually completed.

The passport is a metaphor for the future direction. Hauddy’s current account and key relationships do not certify a person’s legal identity. Nor would a valid signature tell you that an agent made a sensible decision, or that the software using the signing credential had not been compromised. As the Verifiable Credentials model makes clear, checking a credential and accepting its claims are separate judgments. A receiver still decides whose assurances to trust.

In the fuller email example, evidence would accompany the message and bind to its content and recipients. It would describe this agent acting for this linked account under this authorization. Checking it would require compatible software; this is an exploratory design, not a badge Hauddy can already put into Gmail. The point is to make the authority available for inspection wherever the action arrives.

---

There is a small, useful piece of work between that vision and the software we have now.

Every application connection comes with chores. Someone has to protect and refresh the credential, translate the agent’s request into something the application understands, and check whether the action is permitted. When the provider stops answering, someone has to work out whether the request failed or merely lost its reply. This is another version of the integration I kept rebuilding, and it is work Hauddy could make reusable for other builders too.

Imagine linking an email account and allowing one agent to create drafts there. The agent asks Hauddy to create a draft. A connector checks the grant, uses the application’s credential, and records the result. The agent gets an outcome. The credential stays with the connector.

That separation matters because a promise in a prompt is a fragile place to keep a permission boundary. The software controlling access has to enforce it. An agent allowed to prepare a draft should not be able to retrieve the underlying credential and use it to send. Protected storage and a narrow interface have to work together. This follows the existing principle of restricting access to the resources and actions required.

Creating one email draft is the next proposed experiment. First with a fake provider, then with an explicitly linked test account. Gmail is the candidate, subject to reviewing its permissions. Today’s connectors let outside assistants access Hauddy messages and files; this would extend the connection outward into an application. Sending messages and portable proofs would come later.

The experiment earns its keep if the limits hold. Creating the draft is only half the result; the other half is refusing the wrong agent, or the right agent after its grant has been withdrawn. If a response goes missing, trying again should not fill the account with duplicate drafts. The person should be able to see what happened. Those are modest outcomes, but they would give the larger claims something solid to stand on.

They would also make the division of responsibilities easier to see. The model proposes the content. The harness organizes the work. The connector enforces the permitted action. The application stores the draft. These parts have to cooperate, and their boundaries take work to maintain. Keeping them distinct gives us a chance to replace or improve one without handing the whole arrangement to a single supplier.

---

Hauddy would defeat its own purpose if every route out of someone else’s enclosure ended at ours.

That is why the open-source part is essential. The code is available under Apache-2.0 today. The direction is for the same kind of independent infrastructure to be usable on a person’s machine, within an organization’s own environment, or through a provider they choose. A company should be able to keep internal context and permission decisions inside its boundary. It should decide which connections cross that boundary and on what terms.

Local messaging is a starting point. The fuller context and application-grant system is still ahead. So is an ecosystem in which different operators can issue evidence that other systems understand. Hauddy’s hosted service is centrally operated today; publishing its code does not by itself create federation.

For that wider arrangement to work, providers would need compatible formats and clear meanings. A receiver would need to know what an issuer actually checked before making a claim. Revocation would have to reach the place enforcing access. Changing providers would have to preserve useful evidence without automatically carrying permissions into places they do not belong. Open code lets people examine an implementation. Common rules let separate implementations cooperate.

Transparency also has an everyday meaning. Can the person see what their agent accessed? Can an administrator explain why a request was refused? Can a builder inspect how a connector uses a credential? Can someone compare the promises in the documentation with what the system actually does? Trust has somewhere to grow when those questions have inspectable answers.

That visibility should serve the people involved. It should not require publishing everyone’s activity. An application checking permission for a draft has no need for a dossier of the owner’s other agents, contacts, and work. We should disclose what the action requires and be able to explain why it requires it.

There is a cost to all this independence. An integrated product can make choices on behalf of its users and spare them the seams. A modular system has to make those seams work well enough that people do not spend their days repairing them. I began Hauddy because I was tired of being the integration layer. Replacing that job with a more principled version of the same job would be a poor result.

Which brings the vision back to the brief moving between two windows.

Above all, Hauddy needs adoption. Someone should be able to make that first connection without my help, complete useful work, and come back because it saved them trouble. The next builder should find enough clarity in the code and documentation to fix a problem or add a missing connection. Repeat use and contributions are how we find out whether this architecture belongs in people’s work.

If you work with agents, try the local exchange, look at the source, or bring a handoff the current design cannot handle. The useful feedback is often specific: the context that went missing, the permission that was too broad, the connection that took too much effort to make.

Perhaps most people will eventually work through one beautifully made harness. Perhaps they will use several. Either way, I want the choice of window to remain a choice of window. The connections behind it, the context an agent may reach, and the authority under which it acts should be things we can understand, limit, and move deliberately.

I started with the small irritation of carrying work between agents. I would like the result to be something that lets us change the agents, change the tools, and keep working.