From a question-answering AI to an operational workspace

Many organisations have already tried AI chat interfaces. The next problem is more practical: how can a system work with internal documents, select an appropriate tool, execute a controlled task and preserve the procedure for reuse? Brain Company 4.0 is a step in that direction.

The design is multi-agent, multi-model and multi-tool, but the user interacts with one coordinated system. A request can be interpreted by the main model, enriched with authorised company knowledge, routed to an existing capability and checked before an output is delivered. Human approval remains part of the operating model.

How Brain Company 4.0 works: seven connected stages

  1. Multimodal input: requests can arrive as text, documents, images, audio or supported archives, depending on the installed capabilities.
  2. Qwen + OpenClaw: Qwen interprets the task; OpenClaw coordinates the operational sequence.
  3. Brain Core: the Python control layer applies context, permissions and the General or Company mode.
  4. Capability Registry: the system checks registered models, tools, specialist agents and connectors before proposing new code.
  5. Specialised execution: an approved capability is called via a local tool, an agent, an MCP server or a declared REST integration.
  6. Verification and delivery: results and available evidence are checked, and usable outputs are prepared.
  7. Feedback and reuse: validated procedures, results and approved experiences can be retained for future work.
Detailed workflow of Brain Company 4.0: seven processing stages, eight locally tested models, Tool Builder, local-first RAG and learning with Soup
Brain Company 4.0 workflow. Select the graphic to inspect the complete diagram.

One main model, specialist models when the task requires them

Qwen 27B is the main conversational and reasoning engine in the current laptop architecture. A set of eight AI models has been tested locally across relevant tasks. The capability mix includes embeddings and reranking for retrieval, vision-related processing, audio transcription or speech services, and image-related tasks. The registry determines which tested components are available in a given installation; a model being tested does not mean it is automatically enabled everywhere.

For company knowledge, the current embedding component is Qwen3-Embedding 0.6B on CPU. An optional Qwen3 reranker can be enabled, but its impact on retrieval quality and latency should be evaluated against real documents. The objective is not to load the largest possible model at every stage: it is to assign work to an appropriate component.

The Capability Registry and the Tool Builder

The registry is the central catalogue of available operations. It covers built-in tools, tested Python utilities, reusable agents, selected local models and MCP capabilities. Before generating a new tool, Brain Company can look for a verified option already present in the registry.

When a required capability is missing, the Tool Builder is designed around a create → test → register process. Python code generated for this purpose runs in an offline controlled sandbox, and a tool becomes reusable only after checks. This is distinct from granting arbitrary execution privileges to the main AI.

Operational safeguards matter. The laptop workflow limits the number of steps and calls per execution, handles heavy jobs serially, and keeps records of results and tests. Reusable agents operate with declared capabilities and do not give themselves new permissions.

Local-first knowledge, RAG and connected tools

Brain Company can register multiple local folders and authorised knowledge sources. Index updates are explicit, original files remain read-only, and the local index is kept separately from source documents. With RAG, the system retrieves relevant document passages instead of treating an AI model's internal knowledge as the company's source of truth.

As an MCP host, the platform can communicate with compatible servers and declared REST operations via an MCP adapter. Connections require configuration, credentials where necessary and permission checks. On Windows, connection secrets are stored outside SQLite using the operating system's DPAPI protection. A successful local protocol test does not imply that a commercial CRM or third-party service is connected without its owner's authorisation.

Learning + Soup: what is operational, and what is experimental

Soup supports the retention of reviewed outcomes and approved examples, so that useful procedures do not have to be rediscovered each time. This procedural memory is separate from the model's neural weights: saving a successful process does not automatically retrain Qwen 27B.

A focused adapter-learning pilot has been defined for a smaller Qwen2.5 0.5B model. The proposed test uses 30 approved examples, an internal validation split and a separate set of ten unseen examples, with comparisons between the base model and the candidate adapter. Its purpose is to measure whether a specific instruction format has actually been learned, rather than inferring success from a lower training loss alone.

Fine-tuning, adapter promotion and weight-space programming remain research and development activities. They are not being presented as automatically changing the production Qwen 27B model. That distinction is essential when discussing learning in an operational business system.

What is available in the laptop profile?

The current profile includes the local JavaScript interface, a Python Brain Core with SQLite storage, Qwen and OpenClaw orchestration, an MCP connection layer, a multi-source RAG workflow, a capability registry and selected built-in document or media tools. The platform can support production of documents, spreadsheets, presentations and specified video workflows using prepared components, subject to installation and runtime constraints.

Local inference can run without a cloud AI API after the models and dependencies are installed. However, initial installation requires downloads; optional third-party integrations need explicit configuration; and running the platform on a laptop involves measurable hardware, memory and performance limitations. Heavy or complex requests may require a dedicated server or a narrower capability profile.

Release status: Brain Company 4.0 is a locally tested, evolving platform. Not every feature shown in the architecture is a fully generalised or autonomous production capability. Trial suitability depends on a compatibility check and agreed configuration.

Brain Company 4.0: watch the presentation

This short presentation introduces the release and the direction of the product as it approaches TECHXPO Malta 2026. The diagram above provides a more detailed view of the operational architecture.

If embedded playback is unavailable, watch the Brain Company 4.0 video on YouTube.