Introducing SingulaComp: humans and AI agents, one company

Most AI tools give one person one assistant. You ask, it answers, and when you close the tab the work is gone — and nobody else at your company ever sees it. A company does not work that way. Work moves between people, gets checked by someone else, and builds on what the last person learned.

SingulaComp is a platform where humans and AI agents work as one company. Your people and a workforce of AI agents share one organization: the same projects, sessions, agents, skills, connectors and company memory. The agents do the work on real cloud computers. Your people decide what lands.

Underneath it is one idea we think is right for the next decade of software: a company’s AI operation should be code the company owns. Not settings in someone else’s dashboard, but files in git repositories you can read, version, review and run.

The organization is the company

In SingulaComp, your organization is your company: a name, a domain and a sentence about what it does. People join it with a role — owner, admin or member. Agents join it too. Each agent is a principal with a role of its own and a tightly scoped reach into your tools, so one permission model covers both. The audit log names who did every action: a person, or an agent and the person it acted for.

Seats are for people. A seat is a member of your account, and an agent never takes one. Agents draw their compute and their managed-model tokens from the account’s pooled credits.

Set it up once, for everyone

The organization’s Customize holds what every project runs with. Owners and admins set it once, and every project inherits it: the Common project the whole team shares, each person’s Personal project, and every project you add.

• Agents. Markdown personas with a prompt and a scoped reach into tools. Install one from the marketplace or write your own. An edit in Customize reaches every project.
• Skills. Markdown plus scripts that encode how your company does a specific job. A skill rides into every session, so what the company learns compounds in one place.
• Connectors. 3,000+ apps, plus MCP servers and any OpenAPI, GraphQL or HTTP API, connected once for the whole organization.
• Models. Your own key for any major provider, the ChatGPT subscription you already pay for, or SingulaComp-managed models. Pick the default once; switching provider is a setting, not a migration.
• Secrets. Encrypted values that every project inherits, or that one project keeps for itself.

Projects are shared

A project is one line of work: a git repository plus the sessions that work on it. A project’s sessions share one cloud computer. Each person works in their own session, so nobody waits for anybody, and what one session leaves on the machine is there for the next. Every session is open to the project’s members: read what an agent did, pick it up, carry it on.

• Common is the project the whole organization shares. Every member can open every session in it.
• Personal is yours alone. Nobody else can open it — owners and admins included.
• Your projects — one per line of work, each on a cloud computer of its own. Work that must not share files goes in a separate project: projects never share a machine.

Above is the Common project of Tidewater Labs, the example company in our screenshots: three people, three sessions, all open to the whole project. Sharing a machine comes with one caution: two sessions that edit the same file at the same time overwrite each other. Give parallel work different files, or commit before another session picks up the same ones.

What happens when you hand off a task

Day to day, you describe a task in plain language in the web app and get a finished result back. Here is what happens underneath:

• A session starts in a project. It is its own conversation, owned by whoever started it, and it runs beside the project’s other sessions.
• The project’s cloud computer runs it. The first session boots the machine from a content-addressed snapshot of the project’s image; later sessions join it. The repo is cloned onto a branch cut from main, the one branch the project’s sessions share, so the work never starts on main itself. No upstream git token enters the machine: SingulaComp’s git proxy resolves the credential on the server.
• The agent works. It reads and writes files, calls the organization’s connectors, and commits its progress to that branch.
• It proposes the work. When it is done, the agent opens a change request — a summary plus the exact diff — and hands it to a person.

The cloud computer is disposable by design, and git is the only record that outlives it. Pushed work survives the machine; a merged change request makes it permanent.

Agents propose. People decide.

The change request is the heart of the trust model. When an agent wants to keep something — code, a new skill, an edited agent, a change to the manifest — it commits, pushes and opens a change request toward main. You see the exact diff, with conflicts flagged up front, and the merge validates singulacomp.yaml before anything lands. Until it merges, the work is proposed, not applied.

Change requests, the connector calls you set to ask first, and the outputs agents submit for sign-off all wait in one Review inbox for the whole organization. Whoever holds the role opens an item and decides. A change request ships, or goes back to the agent with a note; a gated call runs, or it does not.

What an agent may do is written down too. Its grant in singulacomp.yaml lists the connectors, secrets, skills and SingulaComp permissions it holds, and grants are deny-by-default: an agent you add holds nothing you did not list. A session pushes only to the branch its project’s sessions share, unless a grant says otherwise. The default agent every new project starts with is granted all, so day one works; narrow it once you know what the project needs.

Tools without handing over the keys

SingulaComp connects your agents to the apps your team already uses — Slack, Gmail, Notion, Salesforce and 3,000+ more — and to MCP servers and any OpenAPI, GraphQL or HTTP API. Connectors belong to the organization. An owner or admin connects an app once, and every project uses it. A shared account serves everyone, and any member can add an account of their own for their Personal project.

When an agent calls a connector, it never holds the credential. SingulaComp brokers each call on the server: it resolves the credential, checks the agent’s grant and the connector’s policy, runs the call, records it and returns the result. The key never enters the cloud computer.

Policies govern the actions: each one can always run, require approval, or block, matched by tool name. Let an agent read freely, and stop it before anything sends, posts or pays. Approval is off by default, so set it on the actions that matter.

Everything is code you own

Most people never open a config file. They click, and SingulaComp writes the change. Underneath, every agent, skill, trigger and agent grant is a file in a git repository your company owns: one for the organization, and one per project. Click or edit the file — the change is the same.

Each project’s manifest, singulacomp.yaml, sits at its repo root. Here is the one for Forecast API, a project of Tidewater Labs:

# singulacomp.yaml — the Forecast API project of Tidewater Labs.
singulacomp_version: 2
default_agent: engineering

project:
  name: forecast-api
  description: The tide and swell forecast API that marinas build on.

# Names the project expects. The values live in encrypted secrets.
env:
  required: [DATABASE_URL]

# The cloud computer the sessions share: your image, your hardware.
sandbox:
  default: forecast
  templates:
    - slug: forecast
      dockerfile: .singulacomp/Dockerfile
      cpu: 4
      memory: 8

# Grants only. Each agent's prompt and model live in its .md file.
agents:
  engineering:
    connectors: all
    secrets: [DATABASE_URL]
    skills: all
    # Push and open change requests; no merge grant.
    singulacomp_permissions: [project.gitops.push]

# Work that starts on a schedule, with nobody in the room.
triggers:
  - slug: nightly-drift-check
    type: cron
    cron: "0 0 6 * * *"
    timezone: America/Los_Angeles
    prompt: |
      Compare yesterday's forecasts with the buoy readings.
      Open a change request that recalibrates every station
      that drifted.

The agents every project shares, and the connectors, live in the same kind of file in the organization’s config repository, marked scope: org:

# singulacomp.yaml — the config repository of Tidewater Labs.
singulacomp_version: 2
scope: org

# Every project of the organization runs these agents.
agents:
  sales:
    connectors: [gmail]
    skills: all

# Connected once for every project. No credential lives here.
connectors:
  - slug: gmail
    provider: composio
    app: gmail
    policies:
      - match: "*send*"
        action: require_approval

That is a company’s operating setup in a few dozen lines. The trigger sweep reads triggers:, the sandbox builder reads sandbox:, and the connector layer reads connectors:. Each agent’s behavior — its prompt and its model — lives in its own markdown file beside them.

It compounds

Because the whole setup is versioned files, none of it resets tomorrow. Every agent you shape, every skill you teach, every connector you add and every note your agents keep accumulates in your organization and gets more capable week over week. Teammates pick up each other’s sessions instead of starting over.

Work runs three ways: on demand, when someone asks; human-assisted, when the agent checks in for the calls that matter; and automated, when a schedule or a webhook starts a session with nobody in the room. Any agent can edit its own configuration and propose the change, so the company files patches against itself — and a person decides which ones land.