Every AI project starts the same way. You pick a model, wire up a few prompts, and something useful starts to take shape. Then you try to make it production-ready, and the real work begins.
Suddenly you need a persistent state so agents remember context across conversations. You need isolated execution for business logic. You need role-based access so the right people see the right data. You need somewhere to store files, a way to query your databases safely, and a deployment setup that keeps client data exactly where it belongs. Before long, you’re spending more time on infrastructure than on the actual application.
This is the problem Sinas was built to solve. It’s an open source AI platform that brings agents, functions, state management, database queries, file storage, and templates together behind a single API, deployable anywhere via Docker Compose.
Sinas was created by Kjeld Oostra, who leads our AI & Data initiatives and joined WeAreBrain as part of our recent merger with Pulsr. It’s become the platform we build our AI product work around. This is our introduction to it, and an honest account of why we think it matters.
Why AI infrastructure keeps getting rebuilt from scratch
The pattern is consistent across almost every production AI project we’ve been involved in. Teams start with the intelligence layer — the prompts, the models, the agent logic — and defer the infrastructure questions until they can’t anymore. Then those questions arrive all at once:
- How does the agent maintain memory between sessions?
- Where do the functions handling business logic actually run, and how are they isolated?
- How do you give one team access to certain agents without exposing everything else?
- What happens to the data: does it leave your infrastructure, and if so, where does it go?
Most teams answer these questions by assembling a custom stack: a vector store here, a serverless function setup there, a bespoke auth layer, a separate file storage solution. It works, but it’s expensive to build, harder to maintain, and almost impossible to replicate cleanly across multiple projects.
This is the core of the AI agent infrastructure problem. The intelligence layer is increasingly commoditised. The operational layer beneath it is not, and most available tooling wasn’t designed with production agent applications in mind.
What Sinas actually is
Sinas is best understood as a unified backend for AI-powered applications. Rather than assembling separate services for each concern, it provides six integrated subsystems behind one API with consistent authentication and role-based access control throughout.
| Subsystem | What it does |
| Agents | Multi-provider LLM agents with tool calling, streaming, and agent-to-agent orchestration |
| Python functions | Serverless execution in isolated Docker containers, triggered by agents, webhooks, or schedules |
| State management | Persistent key-value storage with namespace-based access control across conversations |
| Database queries | Parameterised SQL templates against PostgreSQL, ClickHouse, or Snowflake, usable as agent tools |
| Files and templates | Versioned file collections with metadata validation and Jinja2 templates for dynamic content |
| Skills | Reusable instruction documents that agents retrieve on demand, without bloating system prompts |
The design principle is straightforward: an agent that can call a Python function, query a database, retrieve a relevant skill document, maintain memory across a conversation, and send a templated email (all through a single coherent API) is dramatically faster to build and easier to reason about than one assembled from separate services.
Sinas supports OpenAI, Anthropic, Mistral, and Ollama, letting you configure a different provider per agent. Agent-to-agent calls happen via an async queue rather than recursive blocking, which matters at scale. Everything is defined in YAML for optimal version control and replication, and additionally can be configured through API and a web client.
Built for production, not just prototypes
There’s a meaningful difference between an AI tool that works in a demo and one that holds up in production. The gap usually comes down to the operational layer. Sinas addresses this with features that are native to the platform rather than bolted on afterwards:
- Role-based access control that is granular and hierarchical, with wildcard matching and scope inheritance built in
- Full request logging with method, path, status, duration, and permissions used, giving you a complete audit trail without additional tooling
- A management console for configuring resources visually, testing functions, and interacting with agents directly
- Declarative YAML configuration with idempotent apply, change detection, and dry-run mode so infrastructure changes are predictable and version-controlled
Deployment is a single Docker Compose command. The full stack — consisting of numerous microservices and proven open source technologies — comes up together. The self-hosted AI platform you run in development is identical to what goes to production, whether that’s a cloud VM or an on-premises server.
This is what separates Sinas from visual AI builders that work well for prototypes but struggle when production requirements arrive. You don’t hit a ceiling and discover the features you need are locked behind an enterprise tier.
Why open source matters here
Data sovereignty isn’t a feature for many of the projects we work on, it’s a hard requirement. Clients in regulated industries, European companies with GDPR obligations, and organisations handling sensitive internal data need to know exactly where their information lives and who has access to it. A SaaS AI platform, however well-designed, can’t always provide that guarantee.
Sinas is licensed under AGPL v3 and self-hosted by design. The implications are concrete:
- Your data stays on your infrastructure, full stop
- Deploy to EU data centres for GDPR compliance without architectural compromises
- Integrate with your existing identity provider via OIDC
- Inspect every line of the codebase, no black boxes
- No usage-based pricing that scales against you as your applications grow
For agencies and consultancies delivering AI products to clients, this also means clean data separation: one Sinas deployment per client, isolated namespaces, and a handoff process that doesn’t depend on a SaaS account transfer.
The open source AI agent platform space is forming quickly. We believe the projects that earn long-term trust will be the ones built on transparency and user control. That’s a principle we share with Sinas, and a commitment that runs through everything we’re building at WeAreBrain post-merger.
Where things stand, and where they’re going
Sinas is live, open source, and actively developed. It’s at an early but serious stage, which means now is a good time to explore it, build with it, and contribute to shaping what it becomes.
If you’re a developer evaluating AI agent infrastructure for a production project, the documentation covers everything from deployment to RBAC configuration to agent-to-agent orchestration. If you’re an agency or product team thinking about how to deliver AI applications without the recurring cost of rebuilding the same backend every time, it’s worth an hour of your time.The GitHub repository is at github.com/sinas-platform/sinas and the full documentation is at docs.sinas.co. We’re building this openly and we’re interested in the conversations it starts.
