AI & Technology
Agent Platforms, Edge vs. Cloud
Which agents run on-site vs. in the cloud, the platforms we work with, and the SDKs that tie them together — any major model, one set of rules.
Not all AI agents run in the same place. Some need to be on-site — physically close to the software they interact with. Others run in the cloud, created per task and destroyed when the work is done. Understanding where each type runs helps you understand what Connected Spaces is actually doing for your business and why the architecture is built the way it is.
Edge Agents vs. Cloud Agents
The clearest split in our agent architecture is edge vs. cloud.
| Edge agents | Cloud agents | |
|---|---|---|
| Where they run | On-site — on your premises or close to source systems | In the cloud, managed by Connected Spaces |
| What they are for | Legacy software with no API; computer-use scenarios; on-site data collection | Drafting, monitoring, analysing, preparing — most everyday work |
| How they communicate | Phone in to the platform with what they collect | Run inside the platform natively |
| Lifecycle | Ephemeral by design — created per task, destroyed after | Ephemeral or persistent, depending on the job |
| Example | ClawdBots, Hermes, a vendor's desktop agent (computer-use mode) | CNX ephemeral agents, CNX persistent agents |
Edge agents phone in. They do not hold the keys to the house. Their job is to collect information that can only be gathered on-site, then report back to the platform. The platform handles decisions, approvals, and consequential actions — under the same human-approval governance that applies to every other agent.
On-Site and On-Prem: What Edge Agents Handle
Edge agents are the right tool when:
- The software you need to interact with was built before APIs were standard
- A tool simply has no API — the only way to use it is to operate the interface directly (computer-use)
- Data can only be gathered locally, from a source that is not internet-facing
In these situations, an edge agent runs locally, interacts with the system the way a human would — reading the screen, navigating menus, extracting the data — and phones the result back to the platform. The cloud agents then take that data and work with it.
Examples of edge agents we work with:
- ClawdBots — the proprietary edge-agent architecture built for on-site data collection; ephemeral by design
- Hermes — a persistent edge agent for longer-horizon local jobs that benefit from continuity between sessions
- A vendor's desktop agent (computer-use mode) — an agent running locally and operating software interfaces directly; a workaround we can apply where computer use is the best option for a legacy or no-API system
Any Model, One Set of Rules
We are a multi-model operation. Your agents run on OpenAI, Anthropic or Google models depending on the job, through one integration layer. What stays constant is the rulebook: the same scoped permissions, approval gates and audit trail whichever model is underneath. We pick the model for the task; you never have to pick a vendor.
That flexibility is deliberate: it gives you a deployment model that matches your business's regulatory requirements and operational preferences rather than locking you to one provider's terms.
Note
Connected Spaces is not a partner, reseller, or certified affiliate of any AI provider. Under the business terms we use with every AI provider, your data is not used to train their models — but the full data-governance story depends on your deployment configuration, not one provider's terms alone. We configure the deployment model to match your requirements.
The Platforms We Work With
| Platform | Type | What we use it for |
|---|---|---|
| Anthropic models | Cloud | Reasoning where the task profile suits it |
| OpenAI models | Cloud | Reasoning where the task profile suits it |
| Google models | Cloud | Reasoning; Workspace and Ads tooling |
| Hermes | Edge (on-prem / persistent) | Longer-horizon on-site jobs needing session continuity |
| ClawdBots | Edge (ephemeral) | Legacy/no-API systems; on-site data collection; computer-use |
This is not an exhaustive list — the platform is built to add agent types as the landscape evolves. What stays constant is the governance layer: every agent, regardless of platform, operates under the same scoped-permissions, human-approval, audit-trail model.
The SDK Layer
Agent-to-tool communication and agent orchestration run through a set of industry-standard SDKs. These are not proprietary — they are the open, widely-adopted foundations that any competent developer already knows.
| SDK | What it does |
|---|---|
| Anthropic SDK | Integration with Anthropic models |
| OpenAI SDK | Integration with OpenAI models for tasks where that model family is the better fit |
| Google SDK | Google model family access; Google Workspace and Ads tooling integration |
| Vercel AI SDK | Unified streaming and agent orchestration across providers; the connective layer that makes multi-provider work consistent |
The Vercel AI SDK in particular is what allows us to work across model providers without rebuilding the agent architecture each time. You get the benefit of the right model for each task without the fragility of a single-provider dependency.
Agent-to-external-tool communication uses Model Context Protocol (MCP) — the open standard created by Anthropic and now adopted across the industry. MCP is a way to connect an agent to a tool. Any tool that publishes an MCP server can be reached; any tool with an API or a dashboard can be connected by us (QuickBooks, HubSpot and Square are typical).* Running now for clients: email, Google Chat, SMS and WhatsApp, files and Stripe for billing. Other links are part of the Business Partnership plan. See How AI Agents Connect to Your Tools (MCP, Explained) for a plain-language walkthrough.
* Some tools take longer and need a workaround, such as computer use under a person's supervision. Tool names belong to their owners; naming one means we can work with it, not that they endorse or certify us. More on what we connect.
How Edge and Cloud Work Together
A typical flow where both play a role:
- A ClawdBot (edge) runs on-site, opens a legacy system, extracts yesterday's figures, and phones it to the platform.
- A cloud ephemeral agent receives the data, cross-references it against your stored operational history, and prepares an anomaly flag and a reorder recommendation.
- The recommendation surfaces in your approval queue. You approve. The agent acts.
- The ClawdBot's short-term working context is discarded. The insight — the anomaly, the recommendation, the outcome — is promoted to the shared long-term memory layer, available to every agent on the next task.
The edge agent collects what the cloud cannot reach. The cloud agent does the thinking. You approve what matters. The memory compounds.
Related
- ClawdBots: Born, Execute, Gone — The edge-agent architecture for on-site, no-API, computer-use collection.
- Ephemeral AI Agents — Short-term working context discarded; long-term memory preserved — the full model explained.
- How AI Agents Connect to Your Tools (MCP, Explained) — The open standard for connecting agents to tools, and how we connect yours.
- The Nest Protocol — The governance framework that wraps every agent, edge or cloud.
- Governance and Security — Six governance pillars, human approval gates, infrastructure foundation.
- Our Technology Stack — The full non-proprietary foundation Connected Spaces builds on.