How to Bring Together Humans and AI Agents in a Single Workspace

Imagine your work messenger isn't just a stream of messages from colleagues, but a living environment where digital twins handle half the tasks for you. Sounds like a scene from a sci-fi novel, but the folks at Mininglamp-OSS decided to make it happen in code. They're building OCTO — an open platform where humans and AI agents (they call them "Lobsters") work side by side.

The central piece of this whole idea is octo-server. I dug into the repository and want to share why this Go backend deserves your attention if you're thinking about integrating LLMs into your business processes.

What's under the hood of the digital office

If you strip away the marketing fluff around "digital doubles," octo-server is a powerful management layer. It ties together REST API, WebSocket for real-time communication, and agent orchestration. The key feature is that AI here isn't bolted on the side as a chatbot — it's a full participant in conversations from the very start.

The project is written in Go, which makes sense for a system that needs to handle a bunch of parallel connections and requests to different services. WuKongIM is used as the instant messaging engine. The developers didn't reinvent the wheel and went with an off-the-shelf messaging solution, focusing on the interaction logic instead.

What makes this backend interesting

In my experience, it often goes like this: a client wants a "smart assistant," and you start cobbling together workarounds to connect the model's API with the messenger interface. The creators of OCTO took a different approach.

Lobster orchestration is built into the core. The server manages agent sessions, request routing, and tool calls on its own. Agents run on OpenClaw, and the server seamlessly weaves their responses into the overall dialogue.

The architecture is fairly flexible. While MySQL and Redis are offered out of the box, you can swap out the storage and even the messaging engine. The WuKongIM control plane is separated by a thin boundary, so you can plug in your own solution if needed.

The local-first approach is a nice touch. The authors insist that everything that can run on your hardware — chats, embeddings, agents — should run there. Cloud remains an option, not a mandatory requirement. For the enterprise sector, where sending data to OpenAI could get you in trouble, this is a huge plus.

How request processing works

Let's look at what happens when a request comes into the system:

1. Authentication. Tokens, cookies, and even encrypted Diffie-Hellman frames for WebSocket are supported.
2. Authorization. RBAC is implemented here, taking into account organizations and access rights to specific channels.
3. Execution. Business logic runs. If needed, a Lobster session starts or resumes.
4. Dispatch. The message goes to WuKongIM, and if the channel is linked to the outside world — adapters are triggered.
5. Response. The client receives a unified JSON with tracing tags and metrics.

Project structure

The code is neatly organized, so getting around it won't be a problem:

• internal/api/ — handlers live here for everything: users, groups, files, and webhooks.
• internal/service/ — the "brains" of the system, including access control and that agent orchestration.
• internal/agent/ — everything related to Lobsters: session storage and tool execution.
• internal/im/ — client for working with WuKongIM.

graph TD
  subgraph Clients[Clients]
    Web[octo-web<br/>Web / PC]
    Android[octo-android<br/>Android]
    iOS[octo-ios<br/>iOS]
  end

  subgraph Core[Core Services]
    Server[octo-server<br/>Backend API]
    Matter[octo-matter<br/>Task / Todo]
    Summary[octo-smart-summary<br/>AI Summary]
    Admin[octo-admin<br/>Admin Console]
  end

  subgraph Shared[Shared Libraries & Integrations]
    Lib[octo-lib<br/>Core Go Library]
    Adapters[octo-adapters<br/>Third-party Adapters]
  end

  Web --> Server
  Android --> Server
  iOS --> Server
  Admin --> Server
  Server --> Matter
  Server --> Summary
  Server --> Adapters
  Server -.uses.-> Lib
  Matter -.uses.-> Lib
  Adapters -.uses.-> Lib

What to use this for

octo-server is a good fit if you're building a next-generation internal corporate portal. Instead of switching between Jira, Slack, and the AI management console, you get a single entry point. For example, a developer writes in chat: "Create a task for fixing a prod bug," and the agent doesn't just understand the text — it goes into octo-matter and actually creates the task.

The project will also be useful for building custom AI assistants that need access to the entire team's conversation context. Thanks to the open source code and Apache 2.0 license, you can tailor the system to specific security requirements.

How to run it and whether it's worth trying

The quick start is standard for Go projects: clone, build, run with config.

git clone https://github.com/Mininglamp-OSS/octo-server.git
cd octo-server
go build -o octo-server .
./octo-server --config ./configs/tsdd.yaml

Though for full functionality, you'll also need a MySQL database and a running WuKongIM instance. If you don't want to deal with each component separately, they have a octo-deployment repository with a ready-made Docker Compose that spins up the whole stack of services with a single command.

Keep in mind that the project is a derivative work from TangSengDaoDao. This leaves its mark on the code structure. Documentation is still sparse in places, so in tricky situations you'll have to dive into the source code.

Who is this for? First and foremost, those looking for a ready-made foundation for creating self-hosted collaborative systems with deep LLM integration. If you just need a chat, there are simpler solutions. But if you need "Lobsters" that will handle the routine work for you — OCTO is worth spending an evening on.