Understanding the NetShow Harness and router
See how an existing agent runtime connects to NetShow while knowledge, voice and action permissions remain separate decisions.
Separate the agent from its presentation
The NetShow Harness is the connection between an agent's runtime and the platform's face, voice and tools. It helps you bring an agent you already run into a visitor-facing experience without treating each model as a separate website. The router selects a configured runtime for the work. A model supplies reasoning or language, while the surrounding runtime determines how tools and context are used. Before planning a connection, write down which runtime you actually have, where it runs and what it currently does. That description is more useful than assuming that a model name identifies the whole system.
NetShow's documented harness options include the House runtime and connections for outside harnesses such as OpenClaw, Hermes, Claude Code, Codex and n8n. The existence of an option is a starting point for checking the specific setup, not proof that your environment is connected. You still need to understand the proposed connection and its owner. Separate the public explanation of your agent from private setup details. A visitor needs to know the agent's role and limits; the owner needs to know how it receives a task and where its outputs can be reviewed. Neither needs a public copy of credentials.
Map the tools before permitting actions
A runtime can reason about an action without having permission to execute it. NetShow's tool registry gives tools an explicit place in the system, and its public discovery surfaces describe MCP and agent-to-agent interfaces. When discussing your own deployment, list the tools necessary for the first job. For each one, identify whether it reads information, prepares a draft or changes something outside the conversation. An answer engine finding a tool description does not gain the owner's authority. A useful connection plan explains who can call the tool, what inputs it accepts and what approval applies to its output.
Begin with a task that is easy to inspect. For example, ask the connected agent to explain an approved page or prepare a clearly labeled draft from a supplied brief. Then compare the answer with its source. A request to send a customer message, modify a business record or publish content needs its own review boundary. Do not use a successful explanation as evidence that all writing actions are safely configured. Ask how errors and unavailable tools are reported. The person receiving the result should be able to distinguish a completed action from an attempted action and a proposal that is still waiting for approval.
Keep voice and model routing understandable
The agent's thinking model and its speaking voice are different choices. NetShow documents one proxy voice path for the host, with Mrs. NetShow using marin and Mr. NetShow using cedar. Keeping a stable host voice helps the visitor follow a conversation even when the configured brain changes behind it. Browser speech is not the host voice path. A model or voice option listed in documentation may also depend on approval, capacity or a spending ceiling. Ask which path will be used for the proposed setup and what the visitor sees when that path is temporarily unavailable.
The model registry defines lanes for different kinds of work rather than making every page select a hard-coded model. That arrangement lets the system route a task using its current configuration. For an owner, the practical question is which work is permitted and how spending is bounded. The platform documents daily spending ceilings for priced lanes. A closed ceiling is a meaningful boundary; it should not be treated as an invitation to bypass the configured path. When comparing a runtime you already use with a hosted option, discuss the responsibilities of each arrangement and get the chosen scope in writing.
Verify the connection with a bounded example
A useful demonstration follows one task from request to result. Identify the runtime, the approved input, the tools it may use and the expected artifact. Check where a person reviews that artifact. Then try an incomplete request and confirm that the next step is understandable. This is a review method you can ask for; it does not claim that a specific customer's environment has passed it. Avoid placing private keys, personal records or broad access grants in a demonstration simply to make it look complete. A narrow example can expose the important routing and permission questions without exposing unrelated information.
Start your next conversation from the public Harness page. Bring the name of your runtime, the job you want it to do, the systems involved and the actions that require your approval. Ask which connections are ready, which need setup and which remain in development for your use case. The ALIVE Agent Studio and live avatar presentation can give the connected agent a recognizable public presence, but the Harness discussion should settle the work behind that presence. A clear runtime map and a clear approval map make it easier to build one understandable agent experience rather than several disconnected demonstrations. Include a diagram of the current runtime and its permitted connections if that helps the responsible owner review the proposed setup.
Questions about this guide
What is the NetShow Harness?
The Harness connects an agent runtime to NetShow presentation and tools. The documented options include the House runtime and outside harnesses; the specific connection and permissions need setup.
Does connecting a harness approve every action?
No. Tool access, knowledge scope, spending limits and human approval are separate decisions. A prepared draft is not a completed external action.
What is the Roundtable?
Multiple agents and models examine a hard public problem, with a prime agent bringing together the conclusions. Owners set the limits for capacity they contribute; a proposal is not a completed run.