Make Introduces MakeOS and Agent Upgrades: What Is Available and What Comes Next

Make used its October 20 Waves event to introduce MakeOS and expand tools for building, inspecting and governing AI agents. Some capabilities are available, while others remain on a waitlist or roadmap—a distinction that matters for businesses deciding what they can deploy today.

Make’s latest product announcements put a practical business question at the centre of the AI debate: once an agent can take actions across company systems, who can see what it did, decide what it may do and correct a mistake? At Waves ’26 in Prague on October 20, the automation company presented MakeOS alongside updates to its existing platform, arguing that visibility and control must accompany greater autonomy.

The announcement is a product direction and a collection of releases, not evidence that every promised capability is generally available or independently proven. Make’s event summary explicitly separates features marked available from those coming soon or later. Its MakeOS page invites people to join a waitlist. That makes availability one of the most important facts in the story.

Why this is an execution story

A chatbot can produce a useful answer without changing anything outside a conversation. An agent connected to business software can create a record, update a customer account or initiate the next stage of a workflow. The second situation introduces permissions, dependencies and accountability that cannot be assessed by looking only at the quality of the text the model generates.

Make’s October 19 explanation of an execution layer divides that surrounding infrastructure into code an agent can run, systems it can reach, knowledge it can consult and boundaries it must respect. The company describes Functions, Endpoints, shared knowledge and governance within that framework. These are descriptions of its intended architecture, rather than a guarantee that a particular customer’s process will always succeed.

The distinction is useful beyond this vendor. Consider an illustrative customer-support workflow: drafting a response, changing an account and issuing a refund are different actions. A system might sensibly allow the first automatically while restricting the others. A model’s ability to understand the request does not determine which action it has permission to perform. That permission has to be established elsewhere.

MakeOS is a new product with a waitlist

The MakeOS introduction promises a shared view of agents and workflows, including their activity, costs and responsible owners. It also describes controls that would block an agent exceeding its limits, ask a person and record the attempt. These are the company’s product claims. The reviewed page does not provide independent operational results establishing how reliably the product performs those functions across different organisations.

The waitlist is consequently significant. An introduction can establish what a vendor plans to offer without establishing that every reader can enable it immediately. Teams comparing products need to distinguish a demonstration, limited access, an announced roadmap and a service they can actually purchase and operate under their own account conditions.

That is also why a single phrase such as “launched” can obscure more than it explains. Make’s existing platform continues to run scenarios, while MakeOS describes a broader destination. A useful assessment follows the specific capability and its stated status instead of assuming that a new product name means every part is ready at the same time.

Maia adds planning, memory and image input

The company’s separate Maia update, dated October 20, provides a more concrete account of changes inside Scenario Builder. Plan mode gathers questions and presents an approach before building after approval. Build mode works through decisions step by step. The update also describes user-controlled memory, image attachments and an error-resolution workflow based on run data.

Those changes address different kinds of friction. Planning can expose an incorrect assumption before modules are added. Remembered preferences can reduce repeated setup explanations. A diagram can communicate branching structure more clearly than a paragraph. Run data can help connect an error message to what a module actually received. None of those functions removes the need to check the resulting scenario against the intended business process.

For example, a visually correct workflow may still use the wrong account or interpret an exception incorrectly. A reviewer needs to inspect the business meaning of the steps, not simply confirm that the diagram looks orderly. The relevant question is whether the result meets the organisation’s requirements under realistic conditions, including missing data and repeated requests.

Process Intelligence starts before automation

Another announcement concerns deciding what should be automated in the first place. Make’s Process Intelligence explanation distinguishes process mining, which uses activity recorded in business systems, from task mining, which examines work across desktop and browser applications. The company says the product is powered by Celonis technology and offers a waitlist for the capabilities.

This addresses an often overlooked limitation of workflow design: the process people describe may differ from the one they actually follow. Work can pause between systems, return for correction or depend on an undocumented manual step. Automating the remembered version may reproduce an incomplete picture rather than remove the actual bottleneck.

Observation, however, introduces its own questions. Make says customers can choose which applications task mining examines and limit the information collected, including switching off text input and screenshots. An organisation still needs to assess the selected configuration, what information it captures and who can access the results. A vendor’s privacy controls are useful tools; their existence does not answer every workplace data-governance question automatically.

Available features and future controls should stay separate

The Waves summary marks agent orchestration, custom roles, private spaces, event subscriptions and audit logs for agents and MCP as available. It places several other capabilities—including granular Endpoints, MCP toolboxes, locked connections and some approval tools—on the future roadmap. OpenTelemetry support is described as coming later.

These labels should guide a deployment conversation. If an organisation’s essential requirement depends on a future feature, an available neighbouring feature does not satisfy it by association. Equally, an announced future control should not be dismissed as if it were an existing defect. The fair description is that the vendor has identified a capability it intends to add, with availability still to be established.

Customers also need to check plan access and their own configuration. A product announcement can describe a platform-level capability without settling whether it is included in a particular subscription or enabled for a particular team. The sources reviewed for this article do not support a universal promise about pricing, access dates or every customer’s entitlement.

MCP connects tools; it does not settle authority

Make’s announcements repeatedly refer to the Model Context Protocol. The protocol’s architecture documentation describes a structure for connecting AI applications with servers exposing tools and other capabilities. That interoperability helps explain how an agent outside one product can interact with resources supplied by another. It is a technical connection mechanism, not a substitute for an organisation’s access decisions.

A tool can be discoverable without being appropriate for every user or every task. A successful connection also says little about whether the underlying action is reversible or whether the input is correct. Those questions require permission checks, application behaviour and process design around the connection. Keeping them separate prevents interoperability from being mistaken for blanket authorisation.

Make says agents act through an owner’s role and connections, with checks when they act. That is an important design claim to test in a customer environment: what happens when a role changes, a connection is withdrawn or an agent attempts an action outside its assigned job? A polished demonstration does not replace those operational questions.

Governance needs measurement as well as a map

The broader context is an established distinction between describing a system and managing its risks throughout use. The U.S. National Institute of Standards and Technology’s AI Risk Management Framework is voluntary guidance for incorporating trustworthiness into AI design, development, use and evaluation. It supplies a separate reference point; it is not a certification or endorsement of Make’s products.

For an organisation evaluating the announcements, meaningful measures might include how often a workflow completes correctly, how exceptions are handled, whether costs can be attributed to a process and whether an operator can reconstruct a failed run. Those are examples of evaluation questions, not performance results reported by Make or independently measured for this article.

It is also necessary to distinguish a visible action from a reversible one. A log may show that a message was sent without making it possible to unsend it from every recipient. A business therefore needs to identify which actions require review before execution and which can safely be corrected afterward. Visibility supports that decision but does not erase the consequences of an action already taken.

What the announcements establish today

The verified development is a new MakeOS introduction and a documented set of platform upgrades presented at the October 20 event. The official event information identifies the main conference day in Prague, separating it from the optional October 19 programmes. Product availability remains a feature-by-feature question, and the company’s claims about reliability and business impact should remain attributed until independently evaluated.

Our earlier report on Google Cloud’s London disruption examined infrastructure availability. This announcement concerns a different layer: how organisations build and govern work on top of connected systems. Both affect whether a useful demonstration can become a dependable business process, but they require different evidence and different tests.