CompanyOS keeps Routines linked to their Products

Agno's CompanyManager.update now copies a Product's stored Routine ids into the new metadata inside the update transaction, under the same write lock that links a new Routine, and drops any routine_ids the caller sends. That routine_ids list is how CompanyOS ties a Routine to its Product. It feeds the Routine count, the failed-Routine count in /company/attention and project auto-completion for refresh Routines.

In earlier releases a metadata edit replaced the whole dict and dropped the list. An agent with SchedulerTools or Studio's update_schedule could also delete a Routine and leave its id behind on the Product, re-enable one whose Product is archived or rewrite its message. We ran the same scenario on both releases against an AgentOS with CompanyConfig on SQLite.

The refusal reads Schedule <id> is a Company Routine. Change it through Company Routines. Triggering a Routine from the tools still works, and plain schedules behave as before.

OS Manager now sends Company work to the right member. Its Company add-on delegates Products, Projects, Tasks, Sources and Routines, setup and status questions included, to Product Manager, so a request like "set up a daily routine for Docs" reaches the member that links the Routine to its Product.

Under user_isolation=True, the Company tools now follow the same ownership rules as the Company HTTP routes:

• Routines declared in code or YAML have no owner. Their Company tool calls used to fail with Caller identity is required under user isolation, and now run unscoped on their own Product.
• edit_company_project and edit_company_task let any writer edit, as the PATCH routes do.
• refresh_company_product archives only the caller's finished work.
• Any writer can add a Routine to a Product, and a new Routine from a /company/setup retry belongs to the caller.

See the cookbook, and learn more about Scheduler tools in the documentation.