Run recurring improvement reviews

Use Company to organize recurring platform maintenance. Start with the review included in the Render template, inspect its proposals, and take one useful task through implementation and evaluation.

Inspect the included review

The template declares an AgentOS Product in app/company.py and an agentos-maintenance Routine scheduled for 09:00 UTC each day.

The Routine asks Company Manager to read the codebase and Agno releases, then propose up to three useful Tasks with source evidence and a verification plan. Its instructions leave approval and execution to you, and auto_accept=False keeps automatic acceptance off.

Open Company in AgentOS and inspect the saved Product, Routine, and schedule. Scheduled reviews use your model credentials and incur usage costs. Confirm the intended schedule or pause it while configuring the platform.

The declarations seed the database. Once the Routine is saved, change the saved Routine to update its instructions or schedule; editing the Python declaration alone does not update that record.

Ask for an initial review

Ask OS Manager:

Review this codebase and recent Agno releases for the AgentOS Product.
Check existing work first. Suggest up to three useful improvements with
source evidence and a way to verify each one. Leave approval and execution
to me, and create no work if nothing useful needs changing.

Read the proposals and their evidence. A useful Task identifies a concrete problem or opportunity and the behavior that would demonstrate completion.

Complete one improvement

Choose a bounded Task and approve it through your Company workflow. Select the configured engineer you want to execute it. Verify its repository and permissions before starting; use the sandbox setup for hosted engineering.

For the first Task, follow the work through each stage:

1. Baseline: retain the failing scenario or evidence motivating the change.
2. Implementation: inspect the proposed code or configuration diff.
3. Evaluation: rerun the relevant cases and check a fresh variant when behavior changes.
4. Review: inspect the final Task status, tool errors, results, and regression coverage.
5. Adoption: merge or deploy only the changes you choose to keep.

An engineer can return a draft pull request when repository write access and the required tooling are configured. The maintenance Routine itself only proposes work; it does not automatically implement, evaluate, or publish those changes.

Expand the review's scope

Once the first cycle is useful, add a Product for an agent or application you maintain. Give it the relevant Sources and a Routine with a clear responsibility, such as reviewing repeated unanswered product questions.

Keep the output specific: identify a gap, link the evidence, propose a change, and explain how to test it. Use an explicit workflow when work must pass through a repeatable sequence of handoffs and approvals.

Continue to Next steps.