Back to Projects

Conjoin

Technology

Conjoin is a backend platform of eight independent services behind one SDK, covering AI, auth, messaging, storage, async infrastructure, billing, databases, and compute.

Conjoin: Build better apps with Conjoin, faster

My role

Conjoin is the developer platform at Delalify. I designed and built the systems it runs on, which are the service routing, the multi-region deployment topology, and the cross-service coordination that lets the eight services call one another. I wrote the networking layer underneath them as well.

Conjoin is a backend platform of eight independent services behind one SDK. Each service runs on its own, and a call that crosses two of them takes the same routing, authentication, and retry path as a call that stays inside one.

The eight services

The AI service ties every other Conjoin service together. It passes private data to a model while enforcing per-user access controls, and it redacts before that data reaches a third-party provider. It runs inference across several models, orchestrates workflows declared rather than coded, indexes Storage without an ETL step, and applies budget limits per project, team, or user. The provider stays pluggable, so a task can move to a different model without its calling code changing.

How eight separate services behave like one

The eight services run as separate programs on separate machines, though a developer calling them should never have to think about that, and a single request will often touch three of them in turn as it checks who the caller is, writes a file, and queues a job for later. Each hop between one service and the next is a place where the caller's identity can be lost, where the call can cross a continent to reach the data it needs, or where one slow service can hold up the two that are waiting on it.

Rather than solving those three problems inside every service, I built the answers into the layer beneath the SDK. A routing layer there chooses which copy of a service to call from where the data already is, while the request itself keeps one identity from its first hop to its last, which spares the third service from having to ask the first who sent it. A single retry policy covering every hop then means that a service failing for a second will not fail the whole request.

What an AI agent can do with it

The SDK gives an AI agent the same single integration to every service that it gives a person. The CLI is built on that same SDK and runs agents of its own, so it can carry out a plain request across the whole platform. AI coding tools such as Claude Code, Cursor, and Codex drive the CLI directly: an agent in your editor or terminal can set up authentication, send messages, query a database, run code, and manage billing. The MCP server exposes the platform over the Model Context Protocol for any agent that supports it.

Conjoin also runs agents. Runtime gives them persistent sessions with writable filesystems and the SDK already in place, while the AI service handles model inference across providers. An agent can therefore reason, call a model, and act on real infrastructure without leaving the platform.

More in Technology

All projects

Search

Search for blog posts, studies, projects, and pages