AI agents this week: stronger models, clearer permissions

On October 12, Meta introduced Muse Wonder and Muse Wonder Full. Its announcement says Wonder is available through the Meta Model API and Muse Code, while Wonder Full is available to Muse Code subscribers. The planned rollout into Muse is a separate step, initially for subscribers; the announcement does not mean every consumer already has the same access.[1]

Meta highlights memory across conversations and persistence when tasks require recovery or another approach. Those are vendor descriptions, not a guarantee that a model will reliably finish your business process. We are not treating Meta’s performance language as an independently established ranking.[1]

Our recommendation: compare it with your existing tool on one repeatable task, such as turning approved project notes into a status brief. Use the same inputs, expected facts and review criteria. Include a missing deadline and contradictory notes. A useful assistant should identify the conflict instead of making the brief look complete by guessing.

Keep the test small enough to inspect every output. Count factual corrections, missing information and review minutes. If you already have an acceptable tool, a launch is a reason to run a comparison, not an obligation to migrate your process.

Google’s October 13 announcement expands Gemini 4 Argon access to developers and enterprises through the API, AI Studio and Gemini platform. It also lists access for Google AI Pro and Ultra subscribers in the Gemini app and AI Mode in Search. This follows the September 30 announcement of a limited initial rollout, so the new development is broader availability rather than the model’s first unveiling.[2][3]

Google positions Argon for complex engineering and professional workflows. It lists introductory API pricing of $2 per million input tokens and $10 per million output tokens, followed by $4 and $20 respectively after November 30, 2026. These are model-token prices, not a quote for running a complete automation; confirm current terms before budgeting.[2]

Our recommendation: use an evaluation task that spans several documents, such as assembling a proposal outline from an approved scope, delivery notes and an inventory of capabilities. Check whether every promised deliverable is supported by the inputs. A fluent proposal that adds an unapproved commitment creates more work for the reviewer.

Budget for the complete run: repeated attempts, tool access, hosting and the time spent checking the result. Record how the system behaves when one document is unavailable. A workflow that reports the gap and preserves a partial draft can be more useful than one that quietly substitutes assumptions.

Background to this week’s releases: Sierra announced Personal Agent Protocol on October 6. Its current documentation, labeled Draft 0.1 and updated October 14, describes how a business can declare the ways an agent may interact with it and limit account access to what the customer and business agree to. This is an evolving proposal, not a newly finalized standard.[4][5]

The draft builds on existing standards including OAuth. Its path-to-1.0 page explicitly warns that revisions may break compatibility and lists payments, push notifications and attachments as open topics. A published draft and a partner list are not evidence of universal interoperability or production support across those businesses.[5][6]

Our recommendation: inventory the actions your own systems expose. Checking a delivery estimate, preparing a change request and actually changing an order should be separate permissions. You can make those distinctions today without committing your production system to an unfinished protocol.

Consider an illustrative service business that prepares a weekly project update. An operator selects the approved notes, the agent drafts an update with links to those notes, and a person checks it before sending. The agent has access to the chosen inputs and the draft destination. Sending remains a separate, explicit action. No client results or measured savings are implied by this example.

For the first week, write down what a complete update must contain: progress, next steps, unresolved questions and named owners. Prepare a small set of representative examples, including an empty input, an ambiguous date and a failed connection. Have the same reviewer assess each candidate tool against the same checklist.

Then compare the whole task with the manual baseline. Include setup time and corrections, not just the speed of the first draft. Decide in advance what would justify a second week. If the draft is fast but the reviewer must reconstruct every claim, narrow the task or improve the inputs before adding more autonomy.

• Define the output and the source material the agent may use.
• Separate reading, drafting and external actions in the permissions.
• Keep a record of input versions, outputs, approvals and errors.
• Measure accepted results and total review effort against the existing process.

The next useful evidence is how these tools behave in repeatable business tasks: whether they preserve source facts, recover visibly from failures and reduce the effort needed to reach an acceptable result. For the protocol, watch implementation experience and compatibility changes as the draft develops.

For now, choose one workflow that matters to your team. Give it clear inputs and a reviewable output. Stronger models expand the options, but the decision to keep an automation should still rest on what happens when people use it.