Cloud Agents Update: Anyone in the Company Can Contribute to the Codebase

From "Engineers Only" to "Everyone Participates"

A notable product development: Cloud Agents now allows anyone in the company to contribute to the codebase, while changes are still reviewed and approved by engineers. This news comes from the official update summary, accompanied by screenshots of the product interface. It pushes the positioning of AI agents further from "assisting with code writing" toward "an organization-level collaboration entry point" — non-engineering roles can also use agents to produce reviewable code changes, while engineering teams retain final sign-off authority.

Breaking Down the Three Updates

Cloud Agents: Contribution Pipeline Opened Up

The first item in the update summary is that Cloud Agents is now open to the entire company: any member can participate in codebase contributions, with engineers completing review and approval. Behind this is a set of permission and workflow designs — the agent generates changes, and humans decide whether to merge them. For organizations long constrained by "only engineers can touch the repository," this means stakeholders, operations, data analysts, and other roles can more directly turn ideas into discussable code changes, rather than stopping at ticket descriptions.

Code Change Review & Approve Mechanism: In mainstream development workflows, code changes submitted by anyone cannot go directly into the main branch; they must be reviewed by at least one engineer with permissions. Reviews typically focus on correctness, readability, test coverage, and security risks, and upon approval the reviewer executes the merge. In the context of "contributions from everyone," review is essentially a responsibility-transfer mechanism: agents and non-engineering roles propose change intents, while engineers bear the quality and stability responsibility after merging. This is also why "opening up the contribution pipeline" does not equal "opening up permissions" — the write-permission boundary of the repository still exists, only the entry point has become wider.

Session and Context Isolation: In agent products, a session typically corresponds to an independent context window containing user instructions, tool call records, and intermediate results. Creating a new session means clearing or resetting the context, thereby avoiding interference between instructions from different tasks. For tasks that need to be advanced over time, sessions also serve as a process trail, making it easy to trace what operations the agent has performed.

Agent Messaging and New Sessions

The second update is "Message and create new chats with Agent." Agent interaction is beginning to have session management capabilities: you can send messages to the agent and create new conversations. This seems basic, but it is a prerequisite for agents to move from single-turn Q&A to sustained collaboration — different tasks are isolated in different sessions, context is not polluted by irrelevant conversations, and teams can more easily track the agent's work process by task.

Model Selector Adds GPT-6.1 Terra

The third item is that GPT-6.1 Terra is available for trial in the model selector. The official announcement did not disclose the model's specific parameters or performance data; the update summary only provides the name and entry location. What is certain is that the model selector is becoming a first-class citizen of the product: users are no longer bound to a single model, but can switch between multiple models based on the task.

Model Selector and Multi-Model Routing: The model selector is a mechanism that lets users switch between different underlying large models within the same product interface. Different models have different strengths in reasoning capability, response speed, context length, and cost. Having multiple models available allows users to choose based on task complexity and also reduces the product's dependence on a single model provider. This design is usually accompanied by routing strategies — for example, simple tasks go to lightweight models and complex tasks go to stronger models. It is worth noting that version numbers and codenames in model names are often vendor-defined, and the parameter scale or benchmark performance cannot be inferred from the name alone.

Impact on Team Collaboration

Looking at these three items together, the product direction is quite clear: lowering the barrier to participation (contributions from everyone), improving interaction continuity (session management), and keeping the model layer open (selector). For engineering teams, the review burden will increase, but the path from requirement to code will shorten; for non-engineering roles, while the barrier is lowered, they are also required to express change intents more clearly.

The complete official information is available at the changelog link. The above content all comes from the update summary itself and does not involve undisclosed pricing, quotas, or performance metrics.

FAQ

Q: Will code submitted by non-engineers be merged directly? A: No. The update summary explicitly states that changes must be reviewed and approved by engineers.

Q: What capabilities does GPT-6.1 Terra have? A: The official summary does not provide specific capability details; it only mentions that it is available for trial in the model selector.

One-line Summary

Cloud Agents opens code contributions to everyone, adding session management and the GPT-6.1 Terra model option.

Paragraph Summary

The article interprets three product updates to Cloud Agents: first, opening codebase contributions to the entire company, allowing non-engineering roles to produce reviewable code changes, though merging still requires engineer review and approval; second, the agent now supports sending messages and creating new sessions, shifting interaction from single-turn Q&A to sustainable, isolated multi-task collaboration; third, the model selector adds GPT-6.1 Terra, whose parameters and capability data have not been officially disclosed. The author believes the three updates point together to three directions: lowering the participation barrier, improving interaction continuity, and keeping the model layer open, and notes that this will shorten the path from requirement to code while increasing the review burden on engineering teams and requiring non-engineering roles to express change intents more clearly.