Agent Operations
AI Employees 1.7.0 Adds Update Notices, Not Automatic Upgrades
The new routine reports an available upgrade; it does not install it. AI Employees' September 19 version 1.7.0 adds monthly kit-version checks and drafted contributions. The repository's release history also shows that its first release was September 3, despite a later launch-style press release.
Citation-ready: AI Employees 1.7.0 adds scheduled update notices and contribution drafts while leaving upgrades and upstream submission to the user; it is an update to an existing repository, not its first release.
Evidence boundary: Repository-authored behavior and security documentation, not an executed audit. No kits installed, accounts connected or outbound actions performed. The kit guard is not an independent send/spend security filter. Publication note: Prepared for September 21, delayed by a deployment failure, and published September 28 after source revalidation. Original event dates are retained; this is not a new September 28 announcement.
What happened and why it matters
Maintenance can be automated up to a decision boundary. A notice, an install and an upstream contribution are separate actions with different effects.
Primary evidence
Primary reference: AI Employees repository release history and security model. Kaleido Field checked the event date and the article's attributed facts against this source.
| Source date | September 19, 2026 version 1.7.0; first repository release September 3 |
|---|---|
| Checked by Kaleido Field | September 28, 2026, CST |
| Source function | agent operations -> maintenance automation and permission boundaries |
The useful September 19 change is narrower than the headline
The update checks a kit's published version and brings a concise notice into its brief. It can also prepare a contribution draft from local improvement notes, with the project describing removal of member-specific material. The user still reviews and decides whether anything leaves the machine.
That separation matters even if an agent is permitted to read a changelog. Downloaded release notes are untrusted information about software, not authorization to run commands they contain. A maintenance record should retain the installed version, proposed version and the user's actual decision.
A scheduling guard is not an outbound-action gate
The security document says its guard checks timing and duplicate execution, while the underlying harness supplies the permission layer. The documented default is preparation, with specific outbound channels released by the user. Those claims need testing in the chosen harness before relying on them.
The repository currently lists 60 routines, while the September 19 press release said 59. This report does not merge those snapshots into a growth claim. It also keeps publication, delivery and measured outcome separate, as in our routine-trigger analysis.
A later release does not change this dated maintenance question
The changelog now also lists version 1.8.0 on September 23. This analysis concerns the September 19 version 1.7.0 update-notification change; it does not call 1.7.0 the latest release.
Evidence boundary
Repository-authored behavior and security documentation, not an executed audit. No kits installed, accounts connected or outbound actions performed. The kit guard is not an independent send/spend security filter.
FAQ
Does a successful scheduling guard prove an agent cannot send a message or spend money?
No. The project explicitly says that guard is not a send or spend filter; authorization depends on the harness and configured channel permissions.