Automate company operations with CompanyOS
Automate company operations by giving agents ongoing responsibility.
You have an agent that writes your Daily Brief and coding agents that can improve it. Now give the platform a responsibility: keep this briefing useful and reliable.
Company OS organizes that work. You define the outcome and the information agents should consult. Routines look for work worth doing. Projects and Tasks capture the proposals, and an executor carries accepted work through to a result you can review.
This is the starting point for a self-driving company: people set direction and decide what to adopt; agents investigate, propose, and carry out the work.
Start with the included Product
Select your deployed platform in AgentOS, open Company, and select the AgentOS Product.
The template already defines it in app/company.py:
| Part | What it does |
|---|---|
| Product | Owns the ongoing responsibility of improving this platform. |
| Sources | Point to the codebase and Agno releases. |
| Routine | Reviews those Sources and proposes useful improvements. |
| Project | Groups work around a concrete outcome. |
| Task | Describes one piece of work, its executor, and the result to review. |
The included agentos-maintenance Routine is disabled by default. Its configured schedule is daily at 09:00 UTC. Once enabled, it asks Company Manager to propose up to three improvements and check existing work before adding more. Automatic acceptance is off.
Company OS is already wired into the template with PostgreSQL, a durable execution queue, and the scheduler. You do not need to build another manager agent.
Ask for one proposal
Start with a manual conversation with Company Manager. This lets you see the quality of its proposals before enabling recurring work:
Review the AgentOS Product and its Sources. Check existing Projects and
Tasks first. Find one useful improvement for this platform and propose
it as a Backlog Task in a focused Project.
Include the evidence, why the change matters, a clear scope, and how we
would verify it. If a Source is unavailable, say so. Do not invent evidence.
Do not accept or execute the Task, enable Routines, or change code.
If nothing useful needs changing, create no work.Inspect the resulting Project and Task in Company. A useful proposal should tell you what is wrong, where the evidence is, and what a successful change would look like. A generic request to “improve performance” needs more investigation before execution.
Company Manager organizes and proposes work. Claude Engineer, Codex Engineer, or another registered agent, team, or workflow executes an accepted Task.
Take a Task through execution
Choose one small proposal and check its brief before accepting it. For a code change, include the repository and base branch, the checks to run, and the desired result: for example, a draft PR with evidence. The sandbox checkout must contain the code being discussed. For a sandboxed executor, the Product must also have a Git Source whose repository URL matches REPOSITORY.url in app/sandbox.py; the template includes that Source when a repository is configured.
- Approve the Project if it is still proposed.
- Open the Task, choose an enabled coding agent as its executor, and move it from Backlog to To do.
- Move the accepted Task to In progress to start a run. Open its Runs tab and inspect the execution, tool results, and any reported blockers.
- When it reaches Reviewing, inspect the result against the brief. Review the PR diff and checks for code changes.
- Mark satisfactory work Done, or return it for changes with specific feedback.
Accepting a Task authorizes execution; it does not merge its PR. Completing the Company Task and merging a GitHub PR are separate actions. Keep your normal code review and deployment process.
If a Task fails, inspect its run and fix the missing prerequisite before retrying. Confirm that the executor is enabled and that its sandbox can access the repository, tools, and test environment named in the brief.
Enable the maintenance Routine
When the proposals are useful, return to Company → AgentOS and enable agentos-maintenance. Check the saved schedule and timezone, then use Run to try it immediately.
Review the new work and confirm that the Routine reuses existing proposals. With automatic acceptance off, proposed Tasks remain in Backlog until you accept them. You can pause the Routine from the same page.
The code in app/company.py seeds the initial configuration. After a Routine exists, edit its saved settings in the UI; changing the declaration does not overwrite your later schedule or enabled-state choices.
Give Daily Brief its own responsibility
The AgentOS Product looks after the platform. A second Product can focus on the quality of the newspaper. Ask Company Manager:
Create a Product called Daily Brief Quality, or reuse it if it exists.
Its purpose is to keep our daily briefing relevant, current, and grounded
in original sources.
Create a disabled Routine called daily-brief-quality-review, using
Company Manager, for Monday at 09:00 UTC. Its job is to review the evidence
we supply, check existing work, and propose at most one useful improvement
as a Backlog Task. Each proposal needs source evidence, a clear scope,
and a way to verify the change. Leave automatic acceptance off.
Do not enable it or execute any Tasks.Give this Product evidence it can actually read: saved example editions, corrections from readers, evaluation results, and the repository containing Daily Brief. Use sanitized files in a configured Source or attach the relevant evidence to the Task brief. A Product description or a URL alone does not grant credentials to another system.
The template's code-defined Sources can reference Git repositories, Markdown files, and websites. Company Manager can add website Sources through chat. For local files or repositories, ask your local coding agent to add declarations in app/company.py using the existing Product ID and paths available to the API host. Include a Git Source matching the coding sandbox's repository URL before accepting its Tasks. Private access and reading production sessions need their own configured access.
Try a manual review against that evidence, then enable the Routine when its proposals are useful. If you already run another improvement schedule, choose which process owns these changes so the two do not compete to fix the same issue.
Expand one responsibility at a time
The same pattern applies to other work:
| Product | Evidence | Useful work |
|---|---|---|
| Documentation | Release notes, code changes, reported gaps | Update an affected guide and check its examples. |
| Customer feedback | Curated support threads and issue reports | Investigate a recurring problem and propose a focused fix. |
| Competitive intelligence | Competitor announcements and your positioning | Research a change and draft an evidence-based update. |
Start with a narrow responsibility and a small number of proposals. As the workflow becomes dependable, adjust its frequency and the work you delegate. The goal is a steady flow of useful, reviewable results.
Next
Connect Slack so your team can reach the platform where they already work.