MakinaRocks

Real time industrial data flows into the platform, but nothing documents a write into an outside system. The PLC connection is the real support, and it is a read. The other named counterparties, GPU servers, storage and network, are the platform's own substrate. The manufacturing industry panel's "integrate AI across design, production, quality, and operations into a single framework" is about consolidating the customer's AI estate, not about agents reaching outside systems.

The internal integrations are real: the platform brings Gitea, MLflow, Airflow, Argo CD, OpenBao, LLM Playground, Chat and Langfuse under one identity plane, and accepts any workload via Helm chart. That is integration into the platform rather than out of it.

Nothing documents authenticated action in an outside system, and an API agent that triggers external system actions, a DB agent that queries databases in natural language and a retrieval agent that consults manuals are not described.

The four agent pages under /en/specialized/ are where an industrial write path into an ERP, MES or historian would appear, and they are not covered here.

Sourcemakinarocks.ai/en/product/runway/ industries section, makinarocks.ai/en/blog/what-is-ai-os/ platform apps section, PLC use-case page carried from the July passread 2026-09-14

Two orchestration surfaces ship with the platform, one of them multi agent by name, and the sequence is left to the customer. "Airflow for orchestration" is a platform app present from installation, and the app catalog carries "Langflow for building RAG pipelines and multi-agent workflows without writing orchestration code", a visual builder for multi agent work.

The composition model is the product's central claim: "The defining characteristic of Runway isn't any single feature"; "it's that AI applications aren't locked into a fixed pipeline. Every component is independent, and how they connect is up to the team", illustrated as "run experiments in JupyterLab, log results to MLflow, and deploy via Argo CD. Or build a RAG pipeline in Langflow and serve it directly through Chat."

Airflow and Langflow are open source components the vendor packages, integrates under one identity plane and ships as part of the platform. MakinaRocks also describes an enterprise AI operating system that orchestrates specialized agents for anomaly detection, predictive maintenance and process control, but that is a claim rather than a named mechanism. No orchestration runtime of the vendor's own is named and no workflow versioning is described, so what is documented is shipped orchestration tooling rather than a model of how agents coordinate.

Sourcemakinarocks.ai/en/blog/what-is-ai-os/ platform apps, app catalog and own-the-os sectionsread 2026-09-14

The components to build a knowledge store ship with the platform, but none is operated over the customer's data. The app catalog offers "vector databases including Milvus, Qdrant, and Chroma DB" and "Langflow for building RAG pipelines", and the unified runtime lists vector databases among the connected components. These ship with the platform and are governed by it: the buyer gets an open source database engine and pipeline builder, one tap away, inside the platform's identity plane.

A vector database is the means to build a maintained structure, not the structure itself. Here the index arrives empty: nothing ingests the customer's manuals, drawings or maintenance histories, no source is indexed, refreshed or permissioned by the product, and there is no schema, refresh path or ownership of what is in the store.

Citation visibility is equally absent, because the vendor operates no retrieval. Shipping Milvus is shipping the empty shelf. The Specialized AI agent lines and DrawX are where a retrieval agent consulting manuals, or extraction from engineering drawings, might be documented.

Sourcemakinarocks.ai/en/blog/what-is-ai-os/ app catalog and unified runtime sectionsread 2026-09-14

Runway controls who may run what, but no gate holds an agent's action for human approval. The platform "controls who can access which apps and data", "all from a single control plane", "administrators can use built-in roles or define custom permission sets", and fine-grained permission controls extend "to every AI application running on Runway". The vendor's analogy is explicit about the kind of control: "In settings, you control exactly what each app can access: camera, location, microphone, contacts. The OS enforces those policies centrally."

Permissions bound who may run what, not what must be approved before it commits. A role that prevents an engineer from deploying an app is an access decision taken once, at configuration time, and nothing describes an approval queue, a human in the loop step or a hold for review state between an agent's output and its effect. The line "the freedom to install any app doesn't mean anything goes" is about which software may run, not which actions may proceed.

A claim that agents suggest setpoint adjustments for human or system approval appears nowhere on the vendor's pages, and the defense industry panel's "maintaining absolute governance and security protocols" is about control of AI deployment, not a person approving an agent's setpoint. The Control agent line at /en/specialized/control is where a setpoint approval gate would be documented if it exists.

Sourcemakinarocks.ai/en/blog/what-is-ai-os/ governance section, makinarocks.ai/en/product/runway/ industries sectionread 2026-09-14

ISO certification badges on every page sit alongside a deep identity and permission surface, though the certificates themselves are not published. The footer of every page carries ISO 27001 and ISO 9001 badges, a Korean Good Software certification mark and a defense innovation program designation. The controls go deeper and are documented as a governance model: "mandate security across all layers via Keycloak-based SSO and RBAC", with the platform handling "authentication, access control, resource management, and security at the platform level", once.

Runway 2.0 "handles this through SSO, RBAC, fine-grained permission controls, and audit logging", "all managed from one place", and "administrators can use built-in roles or define custom permission sets for their organization." The scope is stated too: "this governance layer isn't limited to models and datasets; it extends to every AI application running on Runway", and the platform apps include OpenBao for secrets.

The gap is verification: the ISO badges are images with no certificate number, certifying body, scope statement or issue or expiry date, and there is no trust center or security page in the navigation or footer, where the only legal page is a privacy policy, so a buyer cannot verify the scope of what was certified.

Sourcemakinarocks.ai/en/product/runway/ governance section and site footer, makinarocks.ai/en/blog/what-is-ai-os/ governance sectionread 2026-09-14

Every platform operation lands in a centralized audit log, and an LLM tracing tool ships pre installed. The product page states it as a platform guarantee: "automatically capture every operation in centralized audit logs to ensure 100% compliance".

The governance section addresses "who can access which data, what actions have been taken, and whether the entire operational trail is auditable", and closes with "whether every action is traceable", "all of it managed at the OS layer". Every operation, centrally, as a property of the platform rather than a per-app afterthought, is a run level record.

The second surface is Langfuse, one of the pre installed platform apps. Langfuse is an LLM tracing and observability tool, so the platform ships a surface on which an LLM application's individual runs can be inspected, which lifts this above a traceability claim with nothing behind it.

What is observed is the AI applications and agents running on Runway; the industrial monitoring the specialized agents perform on plant equipment is the product's output, not a record of the agents. No retention period, export path or SIEM integration is documented, and the audit claim is stated at platform level rather than shown as a log schema.

Sourcemakinarocks.ai/en/product/runway/ governance section, makinarocks.ai/en/blog/what-is-ai-os/ platform apps and governance sectionsread 2026-09-14

No agent memory is documented by any route. The platform is described component by component, from shared GPU and storage services to the app catalog and audit logging, and no store of agent state appears in it: no scope, lifetime or carry over between runs. Continual learning applied to its models is state accumulating in model weights, which is retraining rather than something an agent reads back as context.

The vector databases in the app catalog are knowledge stores over the customer's documents and data. A vector index is a retrieval structure, not a memory of what an agent did or decided, and offering three as installable options makes clear these are components the customer fills. Even conversation state is missing: the platform ships "Chat as an AI interface", but nothing describes thread persistence, history retention or context carried between sessions, and storage as an infrastructure service is disk, not state.

Sourcemakinarocks.ai/en/blog/what-is-ai-os/ read in full, makinarocks.ai/en/product/runway/ read in fullread 2026-09-14

Installation in air gapped and disconnected networks is a headline capability, described in working detail, alongside cloud and on premises options and edge execution on industrial computers. The product page offers "instant deployment for air-gapped environments": "securely deploy AI in restricted or disconnected networks.

Automated import pipelines and private package mirrors enable instant execution with zero external dependencies." The mechanism, automated offline packages and private mirror repositories, has a published effect: it "slashes deployment in air-gapped networks from months to two weeks". A vendor that has built package mirroring to make offline installation fast is operating in disconnected networks, not describing an aspiration.

It is stated as a design requirement of the category. The vendor's section on air-gapped and on-premises support reads "in regulated industries like defense, manufacturing, public sector, and financial services, external network access is often restricted. AI applications need to run reliably there too", and poses the customer question "can we develop and deploy in air-gapped or on-premises environments with the same flexibility as the cloud?"

The capability extends to the tooling rather than just the runtime: the full pre-installed suite is stated to hold "even in air-gapped environments", and the defense positioning is to "deploy and control AI in air-gapped and high-security environments with zero external reliance". No region list or residency menu is published for a hosted option, and no installation or sizing documentation exists, but the customer-environment route is documented repeatedly.

Sourcemakinarocks.ai/en/product/runway/ air-gapped feature, results and industries sections, makinarocks.ai/en/blog/what-is-ai-os/ air-gapped support sectionread 2026-09-14

The browsable app catalog holds infrastructure rather than agents. The vendor describes it in app store terms: "An app store surfaces vetted applications ready to install with a tap. Runway's app catalog works the same way", with six installable entries shown (Chroma DB, Code Server, JupyterLab, Langflow, Milvus and Qdrant) plus eight pre installed platform apps. Every one is a development environment, a database or a piece of engineering tooling. A catalog of vector databases is browsable, but it is not a set of agents a buyer adopts.

The units that would qualify are named elsewhere. The primary navigation lists four agent lines under a heading of Agents (Expert Augmentation, Control, Predictive Operations and Machine Vision), each on its own durable URL under /en/specialized/, alongside a separate named product agent, DrawX, described as "turn drawings into decisions with AI agent". Whether those four are adoptable units or four descriptions of one capability set is not settled by anything here, so what is documented is named machinery and named agent types rather than a catalog of adoptable units.

Sourcemakinarocks.ai/en/blog/what-is-ai-os/ app catalog and platform apps sections, makinarocks.ai primary navigation read across three pagesread 2026-09-14

A scheduler and a chat interface ship with the platform, and agents are described acting on real time PLC data, but no event seam of the platform's own is documented. The vendor's PLC use-case page states that agents monitor production conditions continuously from real-time PLC data and act as conditions change; that claim comes from a single use case page.

"Airflow for orchestration" is one of the eight platform apps available from installation and holding even in air-gapped environments, and Airflow is a scheduler, shipped rather than described. Chat is a third channel, "Chat as an AI interface", also pre-installed, and the vendor's illustration of composition ends "build a RAG pipeline in Langflow and serve it directly through Chat." A conversational surface is a channel, though a human-invoked one, so it widens coverage without evidencing autonomy.

No webhook, event subscription, inbound queue or trigger configuration surface appears in the platform description; what is published is a scheduler the customer wires up and a continuous data feed described on a single use-case page. Channel coverage is thin: one real-time industrial feed, one scheduler and one chat interface, all within a single deployment.

Sourcemakinarocks.ai/en/use-case/runway-manufacturing-ai-system-with-real-time-plc-data/ carried from the July pass, makinarocks.ai/en/blog/what-is-ai-os/ platform apps sectionread 2026-09-14

The customer's administrators choose and serve the models, through a model management app that comes pre installed. "LLM Playground for managing large language models" is one of eight platform apps present "from the moment it's installed", inside the vendor's own identity and lifecycle plane: "everything is integrated via Keycloak-based SSO", with "one Runway login, access to everything". A model management surface handed to the customer's administrators answers who chooses, and the playground is the vendor's own app rather than a third party tool.

The vendor confirms the capability in two more places. The unified runtime is described as "model configuration, serving infrastructure, vector databases, and orchestration tooling connected within a single platform", and the vendor's own related resource is titled Runway Update: Permissions, Closed-Network LLM Serving, and Experiment Setup.

Serving language models inside a closed network is the customer running models of their choosing on their own hardware with no provider in the path, and the pre-installed suite works "even in air-gapped environments". A customer can also deploy "a proprietary model serving API" through the Helm path, which is permitted rather than shipped. This covers the Runway platform; the Specialized AI agent lines may run on a model the vendor fixes. No model list, routing policy or selector interface is published in detail.

Sourcemakinarocks.ai/en/blog/what-is-ai-os/ platform apps and unified runtime sectionsread 2026-09-14

Customers can deploy their own software onto Runway, but nothing documents a way for an outside system to call the platform. The extension path is published and unbounded: "Runway supports deploying any workload via Helm chart", "whether it's an open-source tool not in the catalog, a proprietary model serving API, an internal analytics dashboard, or a custom admin tool. There's no vendor-curated boundary."

Governance follows the extension rather than blocking it: "regardless of where an app comes from", whether the catalog, a Helm chart or co-developed with MakinaRocks, "the same authentication, access control, and resource governance applies automatically." A named, standard packaging format with a documented deployment path and automatic policy inheritance is a real extensibility surface, not a marketing claim.

The direction is inward, not outward: Helm charts let a customer put software onto the platform, but no documented API or SDK lets an external system or another vendor's agent drive Runway. There is no REST API, CLI reference, MCP server, webhook or documentation host anywhere in the site navigation or footer. A proprietary model serving API deployed by the customer is the customer's API running as a workload and says nothing about whether the platform itself is callable. An enterprise platform of this kind may well expose APIs under contract, but nothing published asserts one.

Sourcemakinarocks.ai/en/blog/what-is-ai-os/ custom deployment and governance sections, makinarocks.ai navigation and footer read across three pagesread 2026-09-14

A pre deployment harness comes pre installed: experiment tracking in MLflow ahead of a GitOps release. "MLflow for experiment tracking" is one of the platform apps present "from the moment it's installed", and the vendor describes the working pattern in its own words: "run experiments in JupyterLab, log results to MLflow, and deploy via Argo CD." Experiments logged and compared before a GitOps deployment put a change under test, and it is the sequence rather than the tool that makes it one.

The release path is documented alongside it, "Argo CD for GitOps-based deployment" with Gitea for source control, so a model or application change moves from a tracked experiment through a versioned repository into a deployment. The vendor's own related resource names experiment setup as a shipped capability, and the full suite is stated to work "even in air-gapped environments", so the harness is not a cloud-only convenience.

MLflow, Argo CD and Gitea are open source components the vendor packages, governs under one identity plane and ships as the product. The object is what runs on the platform, which for a buyer deploying this vendor's own specialized agents includes those agents.

The tagline of managing the full model lifecycle from planning and risk modeling through operations with continual learning describes lifecycle management, which is not a harness, and continual learning is absorbed into the model.

No scored test cases, golden set, accuracy figure or published evaluation methodology of the vendor's own is described: the harness is named, but its use is not measured.

Sourcemakinarocks.ai/en/blog/what-is-ai-os/ platform apps and own-the-os sectionsread 2026-09-14

The agents act on industrial systems and machine data, with no screen in the loop and no browser or computer use documented. The action path is data and infrastructure, such as real time PLC feeds, Helm deployed workloads and vector databases, with no rendered control to target.

Machine Vision, one of the four agent lines, inspects physical parts and surfaces through cameras, which is seeing rather than driving a computer interface. Breakage when UI elements change has no meaning against PLC tags, Helm charts and industrial cameras.

JupyterLab and Code Server in the app catalog are development environments a person sits in front of, and Chat is an interface to the agents rather than one the agents operate.

The architecture is described in enough detail that an undocumented screen-driving path is implausible; the four specialized agent pages are the only place a computer use claim could appear.

Sourcemakinarocks.ai/en/product/runway/ read in full, makinarocks.ai/en/blog/what-is-ai-os/ app catalog section, site navigationread 2026-09-14