OpenClaw explained — computer-assist By Glen Harvey A new inquiry arrives while you are helping a client. Who researches the company, prepares the proposal, and remembers to follow up? This visual guide by Glen Harvey shows how a connected workflow can help. In a basic chat workflow, you give the model a prompt. It thinks and returns an output. Then you decide what to do with that output. The key idea is: the AI responds, and you take the next step. This describes a basic use pattern, not everything modern AI products can do. You copy, paste, edit, send, and upload. Each hand-off takes your attention. This is the everyday friction that an agent workflow can help reduce. Here, the arrows show the manual steps after the answer arrives. Now look at the agent side. The example job is: when a new lead fills out a form, prepare a proposal and follow-up for approval. That outcome still needs a defined process, connected tools, and clear permissions. Autonomy is something you configure. The flow begins with a contact form. Next comes company research, a LinkedIn profile, and other useful information. Follow the arrows from left to right. These are illustrative steps: each service needs an available, permitted integration. The next row runs from right to left. Check the details, choose relevant case studies, build the proposal, and review it for approval. Follow each arrow in that order. The connected process turns gathered information into a proposal a person can check. Then attach the document, send the approved email, log it in the customer relationship management system, notify the team in Slack, and follow up. The point is a connected workflow that acts on your behalf. External actions still need the permissions and approval rules you choose. So what makes this possible? Let us follow all seven parts of the OpenClaw diagram, one panel at a time. First, you send a message through a supported chat channel. The idea is a familiar conversation interface rather than a new place to work. The pictured apps are examples; support and setup requirements depend on the channel and deployment. Second, the OpenClaw service runs on a machine you operate. That might be a Mac mini or a server. It coordinates the workflow and keeps local state. Local hosting gives you control over that machine. It does not mean every piece of data stays there. Third, a language model supplies the reasoning. The diagram shows cloud providers connected through an API. If you use a cloud model, prompts and selected context can leave your machine. Compatible local models are also possible. The exact data flow depends on your configuration. Fourth, the configured tools perform actions: browsing, organising files, writing code, or controlling a browser. Tool access is deliberate. You decide what the service can reach and where human approval belongs. A connected workflow still needs testing, monitoring, and error handling. Fifth, retained files and configured memory can provide continuity across sessions. That is useful context, not a promise to remember everything or become more accurate automatically. Memory quality depends on what is captured, retrieved, and kept current. Sixth, you can separate agents by role, such as work and home. Distinct workspaces and routing can help organise context. Separation is a configuration choice, not an automatic security boundary. Permissions and isolation deserve their own checks. Seventh, skills and plugins add capabilities. Extensions may connect more tools or communication features. Availability varies, and adding a capability can also add access or risk. Review what an extension does before giving it permissions. Finally, this table compares basic chat, coding agents, and OpenClaw. Treat it as a guide to operating styles. Product capabilities overlap and change. The useful distinction is the combination of self-hosting, chat connections, model choice, and configured tools. OpenClaw can give you a messaging interface backed by a service you operate. Basic chat often lives in a website or app. Coding agents often work near your code. Those are common interfaces, not exclusive categories. You can interact through supported messages, and voice where configured. Other AI products also support more than typed prompts. The meaningful question is which interface fits the workflow you want to delegate. An OpenClaw service can remain available while its host and connections are running. Scheduled and background activity need configuration. Other AI products may also support background jobs. Always on is an operating setup, not an unconditional guarantee. Persistent files and memory can help OpenClaw carry context forward. Chat products and coding agents may also retain history or memory. Compare what is actually saved, retrieved, and governed in your setup. Local files can live on your hardware. Cloud model requests and connected services may transmit data elsewhere. Check the whole path: host, model provider, integrations, storage, and logs. Running your own agent service brings setup and maintenance: configuration, updates, permissions, and security. A managed chat service can hide more of that work. Control and operational responsibility come together. OpenClaw may suit people who want a configurable, self-hosted workflow and accept the operational work. The best choice depends on the job, integrations, technical comfort, and level of oversight you need. Start with inquiry-to-proposal preparation, and keep approval before client messages go out. Measure time saved and consistency before expanding. Talk to Computer Assist about a repetitive business workflow. Original diagrams and explanation by Glen Harvey.