Skip to content
Bright Factory

Eight terminals open and nowhere to keep them. That’s why we built BrightOS

With AI, writing code is no longer the bottleneck. The problem is getting dozens of agents to work with more than thirty people, all in the same way. To solve it we built BrightOS.
Old computer monitors piled up in a field

Today, with AI, you can build a prototype in an afternoon, and somewhere between late 2025 and early 2026, writing code stopped being our bottleneck.

From then on, the main problem became getting dozens of AI agents to work alongside more than thirty people, over twenty of them engineers, all in the same way and without losing the thread from one day to the next. To solve it we built BrightOS, the internal tool we use to run the Bright Factory every day.

Where we started

Let’s go back six months, to an ordinary day for a Symboolic engineer. Email was still checked by hand, then you’d open a terminal, write the prompt for an agent and wait for it to finish, and in the meantime open another one, and then another. Luca Belmonte, Head of Architecture at Symboolic, describes that phase like this.

“Each of us ended up with five Claude Code sessions and three Codex sessions, on completely different projects, all running in parallel. The context switching was brutal, not just for us but for the information too, scattered across the computer, the cloud and the drive.”

Luca Belmonte · Head of Architecture at Symboolic

It didn’t help the process either: to pick up what you’d done for a client three weeks earlier, you had to reopen dozens of windows and rebuild the context from memory, a bit like restarting a machine without knowing where it had stopped.
The agents, meanwhile, were writing excellent code. The problem was everything around it.

The problem wasn’t the agent, it was the team

Anyone can install Claude Code or Codex, but one agent used by one person and dozens of agents used by twenty people are two very different things.

“Claude Code is easy to download, anyone can use it. But when you have ten people working with it at the same time, the results vary enormously from one person to the next.”

Without a shared tool, everyone organises projects their own way, with tools installed differently, rules written into individual prompts, credentials copied wherever they’re needed, and conversations locked away in transcripts that nobody else will ever have the time or the means to read. That might be fine for a prototype. It isn’t for software that has to go into production for a client.

It’s also the question clients ask us almost every day: they want to know how we work with agents, and we consult on this too, because the point isn’t using Claude Code for a small demo on your own laptop, it’s getting an entire engineering team to work with agents. Anyone who has been in software for a few years has seen this story before with databases, when every team picked its own and sooner or later the time came to bring everything back together. The same thing is happening with agents.

And our work doesn’t stop at code. There’s also understanding the problem, gathering requirements, development, release and monitoring software in production, with the logs and metrics that show how it’s used and where it needs to improve. Around all of that sits everything else, from the knowledge we need to share to the context we can’t afford to lose, and each of these steps has its own rules, its own access and its own decisions to keep. So at some point, the question itself changed.

“The question is how, within the Bright Factory, we raise the bar on the quality of what we deliver to our clients.”

From IDE to ADE: what BrightOS is

For years a developer’s tool was the IDE, the environment where you write code. With agents you need something else: an ADE, or Agentic Development Environment, the place where you follow and govern many agents at once.

BrightOS is made of two parts.

  • The canvas is an infinite board where everyone lays out all of their work, from agent sessions to terminals, from documents and notes to the browser, Slack and Linear, grouped by project or by client.
  • The sandbox is a Linux environment that’s identical for everyone and runs on each person’s Mac. It’s where the agents work, with the company’s tools, skills and rules.
The BrightOS desk seen from afar. Each tile is an agent session, a document or a tool; green marks work ready to review and red marks someone waiting for an answer.
The BrightOS desk seen from afar. Each tile is an agent session, a document or a tool; green marks work ready to review and red marks someone waiting for an answer. The clients, projects and people in the demo are fictional.

BrightOS makes five things the same for everyone, in order of importance.

  1. The working tools.
  2. Skills, meaning the agreed way to carry out a task, from a document’s letterhead to the procedure for requesting a review.
  3. Conventions, the rules for working with agents.
  4. The knowledge the work produces, made of conversations, outcomes and decisions.
  5. The agents themselves.

The idea, at heart, is simple: what’s decided once should hold for everyone.
And the name has a specific reason too.

“Every day we work on operating systems that were born before the concept of an agent. I wanted an ecosystem where agents were the primary construct.”

Agnostic by choice

New models come out almost every day, and with them new tools to use them, so nobody can know how we’ll be working six months from now. That’s why BrightOS doesn’t lock in one definitive way of working; it provides the frame we fit it into, again and again. A new agent, a skill, a connector or a panel can be added without changing anything else, and the ground rules stay the same.

The agent is chosen for each session, and today it can be Claude Code or Codex. Canvas, delegation, outcomes and search work the same way with either, and an agent can hand off part of its work to an agent of a different type. When a new agent arrives it will walk into the same workshop and follow the same rules, because the method is ours and the engine can be swapped.

Claude Code fixes a calculation and asks Codex to verify it within 20 minutes, and Codex closes the check with its outcome: done · changed · open.
Claude Code fixes a calculation and asks Codex to verify it within 20 minutes, and Codex closes the check with its outcome: fatto · cambiato · aperto (done · changed · open). The engines are different, but the way of working is the same. The client and project in the demo are fictional.

We use it to build it

One of the convictions Symboolic was founded on is that a company should be its own factory’s first client, and that what we offer clients should be used on ourselves first. BrightOS is the most direct example.

“We work in BrightOS and develop BrightOS, at the same time.”

Every part can be extended, whether it’s a command, a panel, a skill or a connector, and both people and agents can do it, since they use the same app commands.

When an engineer finds a better tool, they propose it and, if it’s accepted, it lands on everyone’s workbench.

On request, an agent writes the “Deploy di oggi” (today’s deploys) panel and adds it to the canvas, with the day’s three deliveries and one in review. The client and data in the demo are fictional.

What has changed

Today Luca’s day starts, quite literally, in one place. In the morning he opens BrightOS and finds the day’s work already laid out, across calendar, clients and development, together with the agent sessions waiting on him. In the demo below it’s Bolt, the assistant each of us has inside BrightOS, that lines everything up in the morning summary: the sessions that are ready, the work waiting for review and the agent paused until it gets permission.

The morning summary Bolt, the BrightOS assistant, prepares for Ada, with three pieces of work to look at and a request waiting for her permission.
The morning summary Bolt prepares for Ada, one of the demo’s fictional people, with three pieces of work to look at and a request waiting for her permission. Projects and data are examples too.

“I went from three tools, with three dashboards to keep an eye on, to just one, which tells me what input I need to give to keep production moving.”

For the people at Symboolic, all of this means having the same tools and the same rules whoever opens the session, work that doesn’t stall from one day to the next, and several agents to follow in parallel, each with its own status and outcome.

What it means for clients who trust us with a project

All of this happens inside the workshop, but it’s for the people outside. Above all, for them. One of the principles on our website is that context is everything, because an agent only works well if it knows the project inside out, and BrightOS is where that context stays, instead of scattering across laptops and chats.

For those who work with us, this means the same standards apply to every project, client credentials never enter the sandbox where the agents work, and every change and every decision has a conversation and a written outcome to trace back to. And the work can carry on outside office hours, so it picks up in the morning right where it left off.

An agent asks to read the logs on a client’s cloud: the card says what it allows, for which client and for how long, and a person approves or denies it.
An agent asks to read the logs on a client’s cloud: the card says what it allows, for which client and for how long. A person then approves or denies it. The client and data in the demo are fictional.