Four parts of a connection
The agent interprets the request and prepares a response. Its adapter or bridge maps the conversation to a router seat and carries messages. WMOS forwards opaque messages to the addressed node. At the destination, another adapter translates a permitted request into the database, API or device operation and returns the result.
Code should handle authentication, input validation, permission checks, retries and duplicate handling. A model can analyze information or propose a plan; it should not be the only mechanism enforcing allowed operations. Define what happens when a request is invalid, a destination is unavailable or approval is missing.
Keep the chat, bind the right session
Codex, Claude Cowork and CLI clients can play the agent-facing role, subject to the capabilities of the installed environment. Sending through MCP and receiving an event that starts work are separate connections. The tested approaches use Codex queue, Claude Code Channels or Cowork Monitor with a receiver. This does not mean every client version supports a one-click setup.
Bind the receiver to the conversation that owns the task, rather than the active window. Record the router seat and target session, then verify a reply reaches that same context. Plan how session replacement, receiver restarts and network permission changes will be handled. Do not send a pending task to an arbitrary open conversation.
First test: a read-only stock inquiry
For an ERP or inventory connection, choose a bounded question such as whether a named item is available at a specified location. Give the destination adapter access to an approved read-only query or API. It validates the item and location, executes that limited operation and returns the stock result with its source and observation time.
The agent summarizes the result in chat. The initial test should not update stock, place an order or change production plans. Compare the returned result with the source system and confirm that an unauthorized write request is rejected. There is no universal database schema: the adapter must map the site's identifiers and meanings.
Next: an approved device setpoint
A device workflow might propose a new setpoint after reviewing measurements. Keep the existing controller responsible for deterministic control and safety. The adapter checks the device, permitted range and operator approval before passing an allowed change through the established control interface. Return the observed outcome, not just an acknowledgment that a request was accepted.
In the smart farm concept, an LLM layer analyzes conditions above existing control. During an outage, local control and an edge buffer are the intended fallback. A lightweight local model is optional and still needs hardware, model and site validation; it is not required to keep established control logic running.
Decide where the connection runs
A public router is usable when the receiver can reach its authenticated endpoint. A private router is usable when the receiver has an authorized route into that network. An external execution environment may require an approved network path; a desktop localhost address is not automatically reachable from a cloud session.
Using a private router alone does not keep all data on site if a cloud model receives the message contents. Choose the receiver and model locations together with the data boundary. This guide describes planning conditions, not a promise that a particular network or client is already configured.
Bring these details to a pilot discussion
Agree on a small success criterion before widening access. A useful first result is one authorized request, the expected source-system outcome and a reply in the intended session, with an invalid request rejected.
- Environment: client and version, operating system, receiver location and public or private network.
- Target: system owner, database or API interface, device protocol and a non-sensitive sample of the expected result.
- Permissions: read-only or approved write scope, approval owner and credential storage location; do not send secret values in the inquiry.
- Verification: expected result, acceptable delay, failure response and who compares the outcome with the source system.