DEV Community: Jay

Giving your agents access to the World Wide Web

Jay — Sun, 12 Jul 2026 14:39:25 +0000

Most AI agents are trapped in a room with no doors.

They can think. They can write. They can produce a surprisingly convincing plan for almost anything. But when the plan requires opening your calendar, finding an invoice, sending an email, or checking an order, they stop.

They know what should be done. They simply cannot do it.

We usually describe this problem by saying that the agent needs “web access.” But that phrase hides an important distinction.

There are two webs.

The first is the public web. It contains articles, documentation, product pages, forums, and news. You access it through search engines and browsers. Giving an agent access to this web is relatively easy. You give it a search tool or a browser and let it read pages.

The second web is the useful web.

It contains your inbox, calendar, documents, customer records, analytics, projects, orders, and conversations. Most of it sits behind a login screen. A browser can display these things, but that does not mean an agent can use them reliably.

This second web is where most real work happens.

Browsing is not the same as acting

When people imagine an agent using the web, they often picture it clicking around websites like a human.

This works in demos because demos are carefully chosen. The page loads correctly. The button has not moved. There is no unexpected popup. The login session is still valid.

Real websites are less cooperative.

Interfaces change. Buttons move. Pages load slowly. Cookie banners appear. Sessions expire. A small redesign can break a workflow that worked yesterday.

Humans tolerate this because we understand what the page is trying to do. Agents usually understand only what happens to be visible at that moment.

A better way for an agent to use Gmail is not to stare at Gmail’s interface and click buttons. It is to ask Gmail directly for unread messages.

A better way to use a calendar is not to calculate screen coordinates for the “Create” button. It is to call the calendar’s API and create an event.

The browser is an interface designed for human hands and eyes. APIs are interfaces designed for software.

Agents are software.

The web is becoming a collection of capabilities

For humans, the web appears to be a collection of pages.

For agents, it is more useful to think of it as a collection of capabilities.

Search messages.

Read a document.

Create an event.

Update a task.

Check an order.

Publish a post.

Each capability is small. But once combined, they let an agent complete work rather than merely discuss it.

Consider a morning briefing.

An agent that can only browse the public web can tell you the weather and summarize the news. That is useful, but generic.

An agent connected to your private web can also tell you that your first meeting was moved, an important client replied overnight, a package is arriving this afternoon, and a project is blocked because someone has not approved a task.

The intelligence of the model may be identical in both cases.

The difference is access.

This suggests that the next large improvement in agents may not come entirely from making models smarter. It may come from giving existing models better connections to the world around them.

A brilliant employee with no access to company systems is less useful than an ordinary employee who can actually do the work.

Authentication is the hidden problem

Connecting an agent to an application sounds simple until you try to build it.

Every service has its own authentication system. Some use OAuth. Some use API keys. Some require unusual scopes. Tokens expire. Refresh tokens fail. Redirect URLs must match. Applications sometimes require approval before real users can connect.

Then there is security.

Reading an email is not the same as sending one. Drafting a post is not the same as publishing it. Finding a file is not the same as deleting it.

The agent needs enough authority to be useful, but not so much authority that one mistake becomes expensive.

This is why the integration layer matters.

It is not merely a collection of API wrappers. It is the boundary between reasoning and action. It decides what the agent can access, how credentials are stored, which actions require confirmation, and what the user can revoke.

The best version of this layer will probably feel boring.

Users will connect an account, approve a few permissions, and continue talking to their agent. They will not think about refresh tokens, callback URLs, schemas, or SDKs.

Infrastructure tends to become important when people stop noticing it.

Agents should ask for abilities when they need them

Today, connecting an agent often begins with configuration.

The user installs a plugin, edits a file, copies an API key, restarts a process, and hopes the schema was entered correctly.

This is backwards.

The user should begin with intent.

“Summarize the important messages in my inbox.”

The agent should recognize that it needs Gmail access. It should explain what permission is required, produce a secure connection link, and continue after the user approves it.

The connection should happen inside the workflow, not before the user knows why it is needed.

This is closer to how humans delegate work.

When you ask someone to arrange a meeting, they tell you if they need access to your calendar. They do not begin by handing you a forty-page calendar integration manual.

Agents will feel much more natural when acquiring a capability is part of the conversation.

Access should not mean unlimited power

There is a temptation to give agents broad permissions because it makes demos more impressive.

This is a mistake.

A useful agent does not need unrestricted control over everything. It needs the minimum authority required for the current task.

Read operations can often happen automatically. Write operations may need confirmation. Destructive operations should require stronger approval or remain unavailable.

An agent could search your inbox without interrupting you. It should probably ask before sending a message to a client. It should definitely ask before deleting hundreds of files.

These boundaries are not obstacles to autonomy. They are what make autonomy usable.

People delegate work to humans using similar boundaries. A new assistant may be allowed to prepare invoices but not transfer money. Trust expands after the system proves itself reliable.

Agent permissions will probably develop in the same way.

The real product is not the integration

An integration is usually described as a connection between two pieces of software.

That description is technically correct and commercially weak.

Users do not want a Gmail integration. They want to wake up to a useful summary of their inbox.

They do not want a calendar API. They want meetings scheduled without six messages going back and forth.

They do not want access to Shopify. They want unusual orders flagged before customers complain.

The integration is only the mechanism.

The product is the completed task.

This matters for companies building agent infrastructure. It is easy to compete by counting integrations. One platform supports a hundred applications. Another supports a thousand.

But users rarely need a thousand applications. They need the five applications they already use to work correctly.

A smaller system can beat a larger one by making the common path dramatically easier.

That is the idea behind tools such as ClawLink: connect an agent to services like Gmail, Calendar, Slack, Notion, GitHub, and Shopify without making the user build OAuth applications or configure each provider separately.

The number of connections matters less than how quickly the first useful task is completed.

The web was built for humans

The World Wide Web began as documents connected by links. It gradually became software delivered through pages.

Now another transition is beginning.

Humans will continue to use pages. But agents will increasingly experience the web beneath those pages: APIs, actions, permissions, events, and structured data.

For a human, Gmail is a website.

For an agent, Gmail is a set of abilities.

For a human, a calendar is a grid.

For an agent, it is the ability to inspect time, detect conflicts, and create commitments.

This changes what it means to give an agent internet access.

It is not enough to let the agent see the world. It must be able to interact with the parts of the world that matter to you.

The first generation of AI products answered questions.

The next generation will complete tasks.

The difference between them will not just be intelligence.

It will be access.

visit claw-link.dev to see how this unfolds in action

ClawLink vs Composio

Jay — Sun, 12 Jul 2026 09:25:24 +0000

ClawLink vs Composio: Which AI Agent Integration Platform Should You Choose?

AI agents become significantly more useful when they can access real applications such as Gmail, Slack, Notion, GitHub, Google Calendar, HubSpot, and Instagram.

However, connecting an agent to these services is rarely as simple as calling an API. Developers must usually handle OAuth, token refreshes, credential storage, permissions, API changes, retries, and tool schemas.

ClawLink and Composio both solve this problem by providing managed integrations that AI agents can access through MCP or tool calling. However, they are aimed at different users.

ClawLink is primarily built for people running personal or self-hosted agents such as OpenClaw and Hermes. Composio is a broader developer platform designed for teams building AI-powered products.

What is ClawLink?

ClawLink is a hosted integration layer designed around agents such as OpenClaw and Hermes.

Instead of installing and maintaining a separate MCP server for every application, users install the ClawLink plugin, pair their agent through a browser, and connect their accounts from the ClawLink dashboard.

ClawLink currently advertises support for more than 100 applications across email, productivity, developer tools, CRM, analytics, marketing, storage, payments, and social platforms. It handles the hosted connection flow, credential storage, token maintenance, tool execution, and integration reliability.

For example, after connecting Gmail, a user can ask an agent to:

Find an email
Summarize a thread
Draft a response
Search for messages
Send an approved email

The agent receives these capabilities as tools instead of treating every incoming email as a chat message. ClawLink’s Gmail integration currently exposes 15 Gmail tools to supported agents.

What is Composio?

Composio is a developer-focused integration infrastructure platform for AI agents and AI applications.

It provides SDKs, APIs, managed authentication, MCP servers, sessions, tool execution, and framework integrations. Its documentation lists support for more than 1,000 application toolkits and over 20,000 tools.

Composio can be used with frameworks and platforms including OpenAI, Anthropic, Vercel AI SDK, LangChain, CrewAI, LlamaIndex, Mastra, Cursor, Claude Code, and other MCP clients.

Developers can configure sessions, restrict available toolkits, select connected accounts, create custom MCP servers, and generate MCP URLs for individual users.

This makes Composio suitable for companies building agents for many customers rather than only connecting apps to one personal agent.

1. Setup experience : ClawLink

ClawLink is designed to reduce the setup process to a few steps:

Install the plugin in OpenClaw or Hermes.
Pair the agent through a browser.
Connect applications from the dashboard.
Ask the agent to use them.

Users do not need to create separate OAuth applications, paste provider credentials into chat, or configure an MCP server for each service.

ClawLink’s documentation describes the OpenClaw setup as installing the plugin, approving browser pairing, and connecting apps from the dashboard. Its Hermes setup follows a similar bootstrap and pairing process.

Composio

Composio also offers managed connections, but its main product is more developer-oriented.

A developer can create sessions, select toolkits, configure authentication, restrict tools, create custom MCP servers, and expose them to an application. Composio also offers Composio Connect, which provides one MCP connection to more than 1,000 apps.

Composio is not necessarily difficult to use, but it exposes more infrastructure because its customers often need more control.

Winner for simple personal-agent setup: ClawLink

Winner for configurable product infrastructure: Composio

2. Integration coverage

Composio has the larger integration catalog.

It advertises more than 1,000 toolkits and over 20,000 tools. That makes it more likely to support specialized or less common services.

ClawLink advertises more than 100 integrations. Its catalog is smaller but focuses heavily on common applications used by OpenClaw and Hermes users, including Gmail, Notion, GitHub, analytics tools, marketing platforms, social media services, and productivity applications.

The practical question is not simply which platform has the largest number.

The better question is:

Does the platform support the applications and actions your agent actually needs?

A catalog of 1,000 integrations is valuable for a SaaS product serving many industries. A focused catalog may be enough for a personal agent handling email, calendar, documents, social media, and business operations.

Winner for total integration coverage: Composio

3. OpenClaw and Hermes support

This is where ClawLink has the clearest advantage.

ClawLink is explicitly built around OpenClaw and Hermes workflows. Its website provides agent-specific installation instructions, pairing flows, integration pages, and example prompts for both platforms.

Composio can also work with Hermes and other MCP-compatible agents. Its documentation and toolkit pages include Hermes integration guidance, and Composio Connect can be used from general MCP clients.

The difference is product focus.

With ClawLink, OpenClaw and Hermes are central to the experience. With Composio, they are two possible clients among many frameworks and platforms.

Winner for OpenClaw and Hermes users: ClawLink

4. Developer flexibility

Composio provides substantially more infrastructure for developers building products.

Its platform supports:

Python and TypeScript SDKs
Framework-specific providers
Managed and custom authentication
User-specific sessions
Account selection
Tool restrictions
Custom MCP servers
API-based server management
Sandboxed environments
Parallel execution

This matters when a company is building an AI application where thousands of users connect their own accounts. The development team may need to control scopes, accounts, tools, authentication configurations, and execution behavior separately for every user.

ClawLink is more opinionated. Its goal is to make integrations available to an existing agent without turning the connection process into another software project.

That simplicity is useful for individuals, freelancers, agencies, and operators. It may be restrictive for a company building a complex multi-tenant platform.

Winner for SDKs and product development: Composio

5. Pricing

ClawLink currently presents two main plans on its website:

Starter: $4.99 for the first month, then $7.99 per month, with unlimited integrations and fair-use tool calls.
Ultra Heavy: $19.99 per month, with unlimited integrations and unlimited tool calls.

The site also states that users can begin with no payment due immediately.

Composio currently uses usage-based pricing:

Free: 20,000 tool calls per month
$29 per month: 200,000 tool calls, with additional calls charged separately
$229 per month: 2 million tool calls, with additional usage charges

ClawLink’s pricing is easier to predict for a personal agent that runs frequently. Composio’s pricing is more aligned with application developers who need usage-based scaling.

However, pricing pages change. Check both platforms’ current pricing before making a long-term decision.

Winner for predictable personal-agent costs: ClawLink

Winner for usage-based product scaling: Composio

6. Authentication and security model

Both platforms aim to remove the need for developers to manually maintain OAuth tokens.

ClawLink states that provider credentials are encrypted at rest, used only for requested operations, and that API response contents are not stored. It also uses browser-based pairing so users do not need to paste a secret directly into an agent chat.

Composio supports two authentication approaches:

Managed applications maintained by Composio
Custom authentication configurations supplied by the developer

Custom configurations can include a developer’s own OAuth application, API keys, bearer tokens, or other credentials.

Composio therefore gives product teams more control over branding, scopes, and authentication ownership. ClawLink offers a simpler hosted model for users who do not want to manage this infrastructure themselves.

Neither platform should be trusted blindly. Before connecting important accounts, review the requested permissions, security documentation, token-revocation process, and available audit controls.

Who should choose ClawLink?

ClawLink is likely the better choice when:

You already use OpenClaw or Hermes.
You want to connect personal or business applications quickly.
You do not want to build OAuth flows.
You prefer predictable monthly pricing.
You want one hosted integration layer rather than many individual MCP servers.
You are a freelancer, operator, agency owner, or self-hosted-agent user.
You care more about ease of use than having the largest possible catalog.

ClawLink’s core value is that it makes an existing agent useful across real applications without requiring the user to become an integration engineer.

Who should choose Composio?

Composio is likely the better choice when:

You are building an AI product for external users.
You need Python or TypeScript SDKs.
You require more than 100 integrations.
You need user-specific sessions and account selection.
You want custom authentication configurations.
You need precise tool restrictions and infrastructure controls.
Your application must scale across many customers.
You are comfortable with usage-based billing.

Composio’s core strength is not merely connecting one agent to apps. It provides a broader infrastructure layer for developers building agentic products.

Final verdict

ClawLink and Composio overlap, but they are not identical products.

Choose ClawLink when you want the simplest way to connect OpenClaw or Hermes to the applications you already use.

Choose Composio when you are developing an AI application and need a large integration catalog, SDKs, session controls, custom authentication, and scalable infrastructure.

How to Connect Gmail to OpenClaw: the three routes, and when each fits

Jay — Sat, 11 Jul 2026 17:39:34 +0000

Every guide for connecting Gmail to OpenClaw walks you through one method as if it's the only one. The top Google result teaches three but spends half the page selling you off Gmail entirely. So here's the map I wish existed when I started: the three routes, what each one is actually for, and the parts the tutorials gloss over.

Disclosure before anything else: I build ClawLink, which is route 3 below. Routes 1 and 2 are real options and I'll describe them straight.

Route 1: your own Google Cloud project, driven by gog

This is the path most tutorials cover, and for good reason: you own the OAuth client, the API quota is free, and the gog CLI is genuinely good. The catch is the prerequisite everyone underplays. Before the first email gets read, you'll create a Google Cloud project, enable the Gmail API, configure an OAuth consent screen, add yourself as a test user, and download a client secret. Budget 15 to 30 minutes for the Console part the first time.

Once that's done, the CLI side is four commands:

brew install openclaw/tap/gogcli
gog auth credentials ~/Downloads/client_secret_....json
gog auth add you@gmail.com --services gmail
gog gmail search 'newer_than:7d' --max 10

Two things the older guides get wrong or skip:

The install command changed. gogcli moved from steipete's personal GitHub to the openclaw org, so guides telling you to brew install steipete/tap/gogcli are pointing at the old location. The commands above are from the current README.

Headless servers are a special case. The OAuth step wants to open a browser. If OpenClaw runs on a VPS, you'll either do the flow through an SSH tunnel or use manual mode and paste an authorization code across machines. It works, but it's the step where most "45-minute setup" estimates come from.

Pick this route if you want full ownership of your credentials and infrastructure, and Google Cloud Console doesn't scare you.

Route 2: Gmail as a channel

This one does a different job than people expect, and mixing it up is how agents end up auto-replying to real contacts.

A channel setup (the community openclaw-gmail plugin, or an IMAP config with an app password) signs the agent into a mailbox. Incoming email becomes messages addressed to the agent, and it replies in-thread, on its own. That's the point: it makes your agent reachable by email. Send it a task from your phone, get the answer as a reply.

What it is not: a way to have the agent work on your personal inbox. The app password grants full mailbox access, the agent responds to whatever arrives, and there's no per-action approval. Run this on a dedicated inbox you created for the agent. Also worth knowing: the plugin flavor still needs Google Cloud OAuth credentials for its API backend, so route 2 doesn't actually let you skip the Console.

Pick this route if "email my agent and it emails back" is the feature you want.

Route 3: Gmail as hosted tools over MCP

This is the route I build, so calibrate accordingly. ClawLink exposes Gmail to OpenClaw as 15 callable tools (search, read, draft, send, labels) over MCP. The OAuth client is hosted on our side, which removes the Google Cloud project entirely: you click Connect, approve Google's standard consent screen, and the agent has Gmail about two minutes later.

The safety model is the part I care most about. The agent holds scoped OAuth tokens, not an app password. It only touches your mail when you ask it something. And the grant is revocable at myaccount.google.com/permissions like any other OAuth app, so trying it doesn't commit you to anything.

Pick this route if you want Gmail working today, on your real account, without owning OAuth infrastructure.

The ban question

Every thread about agents and Gmail eventually gets to "will Google ban my account?" The warnings trace back to a specific pattern: a brand-new Gmail account, accessed only through CLI tools, sending volume from day one. That pattern trips Google's abuse detection no matter which route you picked.

Connecting an established account through OAuth is the supported path; Google shows you a consent screen and you approve named scopes. What stays risky on any route is bulk automated sending: free Gmail caps you at 500 recipients a day, and blowing past behavioral norms on a personal account is what gets flagged, not the connection method.

Choosing in one line each

Own your OAuth client and infrastructure: route 1. Reach your agent BY email, on a dedicated inbox: route 2. Gmail working in the next two minutes with no Google Cloud Console: route 3.

The longer version of this guide, with the full tool list and setup steps for route 3, lives at claw-link.dev/openclaw/gmail. Questions about any of the three routes welcome in the comments; I've hit most of the failure modes personally.