If you've sat through more than two AI agent platform pitches this year, you already know the drill. Someone types a prompt, an agent spins up, a browser opens, applause erupts. The model underneath is almost irrelevant—you can swap GPT-class, Claude-class, and open-weight models in and out, and for most workflows the differences wash out within a quarter. So why are teams still treating model selection as the primary decision point? Because demos sell, and demos look identical.

Why Model Comparison Is the Wrong Frame

The model is not the moat. The platform around the model is—and that's where every painful surprise lives three months in: the agent forgot what it learned last week, the runtime can't actually run your build, there's no way for a 'research agent' to hand findings to a 'writer agent,' and your bill went sideways because pricing was metered on something you couldn't predict. The six dimensions that actually matter are memory, runtime, tools, collaboration, channels, and pricing. A platform brilliant on five and broken on one will still hurt.

Memory: Where Does the Agent's Knowledge Actually Live?

This is the most under-asked question in agent evaluation, and it determines whether your agent gets smarter or just chattier over time. Most platforms fall into one of three memory models: context-window memory (whatever fits in the prompt, gone once the conversation scrolls), vector-store memory (embeddings retrieved on similarity—better but lossy and opaque), and file-grounded memory where durable knowledge lives as real files you can open, version, and correct like any document. Platforms that conflate chat history with durable knowledge are setting you up for a debugging nightmare. Push for inspectable, editable memory—not a mystery embedding blob you'll never be able to audit when the agent confidently gives you wrong information.

Runtime: What Actually Executes the Work?

A lot of 'agents' are thin orchestration loops calling APIs. The moment a task needs to clone a repo, install dependencies, or execute a script, you find out whether there's a real computer behind the agent or just a chat box with delusions of competence. Self-hosted setups like OpenClaw-style deployments give you total control—your data never leaves your hardware, no per-seat cloud bill—but you're now ops: patching, babysitting, dealing with noisy neighbors when builds peg the CPU. Cloud-native platforms offer isolated, durable runtimes without infrastructure overhead but introduce vendor dependency and pricing opacity. The questions that separate a real runtime from a wrapper: Is there a real shell? Can it do Git-heavy work with sane storage for node_modules? Can you watch and intervene while it works? Does the environment persist between runs?

Tools: Can the Agent Touch the Real World?

An agent that can only talk is a chatbot. An agent that can act needs a toolbelt. The baseline in 2026 should include an AI-controlled browser running in the sandbox for automation, a passive viewer for previewing localhost or internal tools, a real terminal shell (not sandboxed), Git with visual diffs and rollback capability, and HTTP/OpenAPI access to existing systems. Nice-to-haves that signal serious platforms: VS Code Remote SSH into the agent's environment so humans can drop in and fix things directly, shareable preview URLs for localhost apps inside the sandbox, and retrieval tools that handle PDFs, images, spreadsheets, and video—not just plain text. Here's a quick sniff test: ask the vendor to clone something real, install dependencies, build it, and serve a live preview URL end-to-end. If they stall at npm install, you've got a demo, not a platform.

Collaboration: One Agent or a Workforce?

Single-agent tools are everywhere. The interesting question for 2026 is whether the platform treats agents as a team. Look for first-class support for multi-agent orchestration—can a research agent hand findings to a writer agent who passes drafts to a reviewer? Real workflows are pipelines, not monologues. Then there's human collaboration: self-hosted setups tend to show their seams here because a box under your desk is implicitly single-user. Team platforms need org boundaries—shared storage, shared billing, member permissions, and scoping for which humans can manage which agents. If a platform can't explain how two agents collaborate or how three teammates share one agent's knowledge, it's a personal tool wearing an enterprise hat.

Channels: How Do Humans Reach the Agent?

An agent nobody can talk to from where they already work is shelfware. Real platforms reach beyond web interfaces to Slack, WhatsApp, Telegram, Discord, Microsoft Teams, and regional players like Feishu/Lark and WeCom. But here's the gotcha most teams forget until it bites: session isolation per channel. If your support agent serves customers over WhatsApp, each phone number must get its own isolated session—one user's history leaking into another's is a privacy incident, not a bug. Ask explicitly how the platform scopes sessions per user, per DM, per group. A useful mental model: channels are entry points (doorways), not memory. Durable knowledge belongs in the memory layer; the channel just routes messages.

Pricing: Does the Model Survive Real Usage?

Pricing is where evaluations go to die because the sticker price is rarely the real cost. Three things to pin down: What's the billable unit and can you predict it? Per-seat punishes large teams, per-token is volatile when chatty agents spike bills, and composite 'credits' systems bundle model calls with third-party API usage in ways that require real workload modeling before trusting estimates. Second: Per what does it scale—per user, per agent, or per workspace? Buda-style platforms bill per Space (their org unit) not per human seat, which can be cheaper or pricier depending on your shape. Third: Where do gated features sit? Browser, Terminal, Git, scheduled automations, and high-performance SSD storage are often paywalled above the free tier. The lesson is to map your actual org structure onto the billing unit—don't trust the vendor's example.

Key Takeaways

  • Memory should be inspectable and file-grounded, not a black-box embedding store you can't audit
  • Runtime needs a real shell with persistent state, Git support, and human observability
  • Tools must include browser automation, terminal access, Git, and API integration—not just function calls
  • Collaboration requires multi-agent handoff plus org-level permissions and shared knowledge
  • Channels demand per-user session isolation to prevent privacy incidents across customers
  • Pricing clarity comes from mapping your specific team shape onto the billing unit before signing

The Bottom Line

The flashy demo will pass—it always does. What you're really buying is boring stuff: memory you can audit, a runtime that actually runs, tools that touch reality, collaboration that scales past one person, channels with clean isolation, and pricing you can forecast. Get those six right and the model underneath barely matters. Get them wrong and no model will save you.