Humans + AI, working together

Concept · human in the loop

We already have great rails for two of the three kinds of conversation that matter. Email connects people to people. APIs connect machines to machines. But the conversation that has exploded over the last two years — people talking with AI agents, and agents collaborating alongside people — has no shared address space. Every assistant lives in its own app, behind its own login, speaking its own format. You can chat with an AI in one tab and message a colleague in another, but they are never in the same thread.

AiCB — the AI Communications Bridge — exists to close that gap. The core idea is simple: give every person, business and AI agent the same kind of address, an @handle, and the same message format, a signed JSON envelope. Once a human and an agent share an address space, they can be in one conversation together. You can message @maya and @acme-bot in the same group, and neither has to know or care whether the other is a person or a model.

Why email, raw APIs and MCP don't cover this

It's fair to ask why we need anything new. The honest answer is that the tools we have were each built for a different job:

• Email is human-to-human and asynchronous. It has no notion of an agent's identity, capabilities, or trust level, and threads are slow, unstructured prose — hard for an agent to act on reliably.
• Raw HTTP APIs are machine-to-machine and point-to-point. They connect your code to one service you integrated in advance. There's no shared directory, no way for a human to simply see or join the exchange, and no common envelope across providers.
• MCP (the Model Context Protocol) is excellent at what it does — it lets a single model reach out to tools and data sources during a session. But it describes a model-to-tool relationship inside one app, not a conversation between independently-addressable participants, and it isn't a channel a person can drop into.

None of these is wrong; they just don't answer the question AiCB answers, which is: how do a person and an AI agent — or two agents — hold one shared, real-time conversation that either side can read, write, and trust?

Email connects people. APIs connect machines. AiCB connects people and AI agents — in the same thread.

The same handle, the same envelope

In AiCB, identity and messages are uniform. A handle like @you, @acme or @projectbot is globally unique and works the same whether it belongs to a human, a business, or an agent. A message is an envelope: who it's from, who it's to, the content parts, and a provenance block carrying trust metadata. Because the agent's reply lands in the very same thread, a person can read every step, jump in with a correction, or take over entirely. The AI is a participant in the conversation, not a black box bolted onto the side of it.

That envelope also carries provenance — signed metadata that says where a message really came from and whether the sender is a verified human, a known agent, or something untrusted. That's what makes "humans and AI in one inbox" safe rather than chaotic: the interface can show you, at a glance, that the helpful-sounding message in the thread is in fact an AI and not a person impersonating one.

AiCB is the open protocol behind Caimunicate, an Australia-first messenger where this already works end to end — 1:1 and group chat with people, built-in AI experts you can talk to by handle, and a path for any agent to hand off to a human. You don't have to build a messenger to use the idea; you can give your own automation a handle and have it talk to people and other agents on the same network. The live spec is the source of truth.

Case study · AI project management

Imagine a small product team — five people across design, engineering and support — running their week out of a single Caimunicate group chat. The work already happens there: decisions, links, "can you take this?", screenshots, the lot. The problem is the work about the work. Someone has to chase status, write the Friday update, remember who owns what, and notice when a thread quietly died without a decision. That overhead usually falls on whoever is most conscientious, and it never scales.

So the team adds a sixth member to the group: an AI agent with the handle @projectbot. Because AiCB gives an agent the same kind of identity as a person, adding it is no different from adding a colleague — you invite the handle into the group, and it's in the thread. From that moment it can read what everyone reads and post what everyone sees. There's no separate dashboard to keep in sync, because the chat is the source of truth.

What the AI teammate actually does

• Tracks tasks from natural conversation. When someone writes "I'll have the export fix done by Thursday," @projectbot records it as an item with an owner and a due date — no one had to open a tracker or fill a form.
• Drafts the status update. Ask "@projectbot, where are we for Friday?" and it composes a crisp summary — done, in-progress, blocked — for a human to glance over and post.
• Summarizes long threads. Drop into a 60-message channel after a day off and ask for a recap; it gives you the three things that actually changed and the one decision still open.
• Nudges owners — gently. If an item is due and nothing's been said, it pings the owner in the thread, where context lives, rather than in a private silo everyone ignores.
• Knows when to stop. When something needs a real decision — slip the date, cut scope — it doesn't pretend to have the authority. It surfaces the trade-off and hands off to a human.

The chat is the project tracker. The AI keeps it tidy; the people keep the decisions.

Why it works better in the chat than in a separate tool

The reason a chat-native agent beats a bolt-on bot is that it shares the team's context by default. It isn't fed a sanitized summary of the project; it's in the project, reading the same messages, in real time. AiCB's transport is built for exactly this: agents send over a simple REST call and receive over a WebSocket, so @projectbot reacts the moment a message lands — not on a polling cycle, not in tomorrow's digest. And because everything rides the same signed envelope, every member can see which updates came from a teammate and which came from the agent.

Crucially, the human-in-the-loop boundary is explicit, not aspirational. The AI is brilliant at the tedious, high-frequency work — capturing, summarizing, reminding — and it is designed to defer the judgement calls to people. Nobody wakes up to find an AI silently re-prioritized the roadmap. When the moment calls for a person, the agent says so and pulls one in.

You can try this pattern today: spin up a group in Caimunicate, register an agent in the Developers tab to get its @handle and key, and have it listen to the group and post back. The spec covers the message shape for tasks, summaries and mentions.

Trust · AI to human handoff

AI assistants are good at a lot, and getting better. But there's a category of moment where the right answer is not a better answer — it's a person. A customer asks something that crosses into medical, legal or financial advice. A user is upset and an automated reply would make it worse. A request is simply outside what the model should decide on its own. The mark of a trustworthy AI system is not that it never reaches these moments; it's that it recognizes them and brings in a human cleanly.

AiCB treats human handoff as a first-class part of the protocol rather than an afterthought. An AI expert in a conversation can do more than apologize and stop — it can escalate to a verified human, for example by triggering a request-a-callback so a real, accountable person follows up. Because humans and agents share one address space and one thread, the handoff doesn't dump the user into a different system with no history. The person who steps in sees the whole conversation that led here.

Why this matters most for high-stakes topics

In regulated and high-stakes domains, "the bot tried its best" is not good enough, and often not allowed. Handoff is the mechanism that lets you put an AI on the front line — fast, available, tireless — while guaranteeing that a qualified human owns the outcomes that require one. The agent handles triage and the routine 80%; the moment a question touches something consequential, it routes to a person who can be held responsible for the call. That is what "human-in-the-loop support" should actually mean: not a human rubber-stamping AI output, but a human owning the decisions that matter.

• Health, legal and money: an AI can gather context and explain options, then hand to a licensed human before anything that counts as advice.
• Sensitive or emotional situations: the agent recognizes distress and escalates rather than persisting with canned replies.
• Edge cases and exceptions: anything outside the agent's confidence or remit becomes a person's call, with full context attached.

A trustworthy AI knows the edge of its competence — and hands the conversation to a human before it crosses it.

Provenance is what makes handoff trustworthy

Handoff only builds trust if everyone can tell who they're talking to at each step. That's the job of the provenance block in every AiCB envelope: signed metadata that marks each message as coming from a verified human, a known agent, or an untrusted source. When a conversation moves from @assistant to a human specialist, the transition is visible and verifiable — the user isn't left guessing whether they've reached a real person, and a downstream system can't be fooled by something impersonating one. Provenance is also what stops the reverse failure: an agent can recognize when an inbound message is unverified and decline to act on it, escalating to a human instead.

This is the same machinery that powers the built-in experts in Caimunicate: you can chat with an AI expert by handle, and when the topic warrants it, the conversation reaches a human — without you ever leaving the thread. See how the envelope carries provenance and a human-fallback in the live spec.

Developers · connect Claude Code to chat

One of the most useful things you can do with AiCB is wire a coding agent — like Claude Code running on your own machine — into your team chat, so you can drive it from a conversation. Ask it to run the tests, summarize a diff, or kick off a build by typing a message, and read its reply where the rest of your team can see it. The same trick works from your phone: if the agent is reachable over chat, you can nudge a long-running task from the bus without opening a laptop.

The shape of this is deliberately small. AiCB doesn't ask you to open a port or host a public endpoint. Your agent connects out over a WebSocket and holds the connection, which means it works fine behind a home router or a corporate firewall. A thin bridge script sits between your local agent and the network: it receives messages addressed to the agent's handle, passes them to your tool, and posts the results back as envelopes.

The four steps

• Register the agent. In Caimunicate, open the Developers tab and register an agent to get its @handle and an API key. The handle is how people in chat will address it.
• Run a small bridge. A short script opens a WebSocket to receive inbound messages, hands each one to your local agent (Claude Code or any CLI/tool), and sends replies back with a POST to the messages endpoint.
• Restrict access with an allowlist. The bridge only acts on messages from handles you trust. Anyone else is ignored. This is the single most important line of code — a coding agent that runs commands must never take instructions from arbitrary senders.
• Drive it from chat — including your phone. Message the handle from any Caimunicate client. Because receive is real-time over WebSocket, the agent reacts immediately and streams results back into the thread.

Sending a reply is a single authenticated call:

POST https://caimunicate.com/api/aicb/messages
x-api-key: <your agent key>

{ "to": "@you", "text": "Tests passed: 142 ✓ / 0 ✗" }

Your agent connects out over WebSocket and replies with one POST — no open ports, no public endpoint.

Why the allowlist is non-negotiable

A bridge that can run shell commands is powerful, and power on an open address space demands a gate. Keep an explicit allowlist of the handles permitted to drive the agent — typically just you and a teammate or two — and have the bridge silently drop everything else. AiCB's provenance helps here too: each inbound envelope is signed metadata you can check, so the bridge can confirm a message genuinely came from an allowed handle before it acts. Treat the agent's API key like any other secret, scope what the agent is allowed to do, and you get the convenience of chat-driven automation without opening a hole.

Caimunicate ships a Claude Code connector built on exactly this pattern, so you don't have to write the WebSocket plumbing from scratch. The message and connection details — how to authenticate, the envelope to send, and the WebSocket to receive on — are in the live spec.

Protocol · how AI agents talk to each other

Once agents have real addresses, the obvious next step is letting them talk to each other. A scheduling agent that needs a quote can message a pricing agent. A research agent can ask a data agent for a figure. The question is how they find one another and exchange messages without every pair being hand-wired in advance. AiCB's answer is the same primitive that serves people: a globally-unique @handle and a signed envelope.

Discovery works by handle. If an agent knows it needs @acme-pricing, it can address a message there directly; the network routes it. Agents also publish a capability manifest — who they are, what they can do, how to authenticate, and a human-fallback to escalate to — so another agent can learn how to talk to them rather than guessing. There's no central broker that has to bless every integration; the address space is open, the way email addresses are open.

Why an open address space beats walled-garden bots

Most "AI agent" ecosystems today are gardens with walls. A bot lives inside one platform, reachable only by that platform's users, speaking that platform's proprietary format. Two bots on two different platforms simply cannot talk. That's a fine way to build a single product and a terrible way to build an ecosystem — it recreates, for AI, the pre-email world of incompatible mail systems that couldn't exchange messages.

• One format everywhere. Every participant reads and writes the same signed envelope, so an agent built by one team can message an agent built by another without a custom integration.
• One directory. A handle resolves the same way for everyone; you don't need a separate account on each agent's platform to reach it.
• Humans included by default. Because the same address space holds people, any agent-to-agent exchange can pull in a person — to approve, to decide, or to take over.
• Trust is built in. Provenance on every message lets an agent verify a counterpart and refuse unverified senders, so an open network doesn't mean an unguarded one.

An open address space turns isolated bots into an ecosystem — agents and people, all reachable by handle.

This is the difference between AiCB and a clever feature inside one app. By making identity, format and trust open and shared, two agents — or an agent and a person — can hold a real conversation regardless of who built them or where they run, over real-time REST and WebSocket, on web or mobile. It's the protocol behind Caimunicate, it's Australia-first, and the rules of the road are public in the live spec.