Linear Has First-Class Agents. Everyone Else Has Bots.
We recently completed a plethora of integrations for Aleq particularly around— getting it to actually do things inside the tools our customers use. ClickUp, Asana, Linear, eventually Jira, maybe Monday but Aleq can now do nearly anything a human can do in 314 different software applications 🙂
Standard pattern every time: OAuth flow, webhook setup, map their task schema to ours, write the adapter, ship it.
Then I opened Linear to build their integration and something clicked.
Linear’s agent isn’t a feature.
It’s a teammate.
AND its powered by 3rd party apps–Linear isn’t trying to control the purse and this sentence alone deserves its own blog post quite frankly, but we’ll leave that for another day.
It has an identity. You can assign it work. It shows up in the timeline like a human. It’s governed by the same permissions as everyone else in the workspace.
Inside Linear, the agent belongs there.
And the second I saw that, I thought: “Oh. This is obviously where everything is going.”
The Obvious Part
Every ops platform already has the same building blocks:
- OAuth2 workspace installs
- Webhooks for events
- APIs to create tasks, post comments, update statuses
- Users, permissions, workspaces
That’s it. That’s the foundation.
Linear just connected the dots differently.
They gave their agent a real identity in the workspace instead of treating it like a floating API token.
And now their agent can do things no one else’s can:
- Be assigned work
- Show up in audit logs
- Get @mentioned
- Operate under workspace policies
It’s not that Linear invented new technology.
They just treated the agent like a member instead of a bot.
The Gap
So here’s the thing:
If you’re building a serious agent — something that needs to operate across ClickUp, Asana, Jira, Notion, Monday — you’re writing completely custom integration logic for each one.
ClickUp has one schema.
Asana has another.
Jira is a whole different religion.
But the behavior you want is always the same:
- Create a task
- Update a status
- Post a comment
- Assign work
- Respond to events
Same intent. Five different implementations.
There’s no standard for how agents should exist inside workspaces.
Not behavior. Not identity. Not governance.
Everyone’s just writing adapters.
The Missing Layer
Right now the stack is:
- OAuth → who you are
- MCP → how models call tools
- Platform APIs → what you can do
But there’s nothing that defines:
- What an agent is in a workspace
- How it should show up
- What verbs it should speak
- How its actions get recorded
- How it gets restricted
That’s the layer we need.
Internally, we’ve started calling our version MAP — Multi-App Agent Protocol.
Not because we’re trying to start a movement.
Because we need it for Aleq anyway, and we figured we might as well think out loud about what shape it should take.
What MAP Would Look Like
This isn’t a spec. It’s barely an outline.
But here’s the shape:
1. Identity
Agents get workspace-level presence, not just API tokens.
2. Capabilities
Universal verbs: create_task, update_status, comment, assign.
Each platform maps their API to these.
3. Events
Normalized webhook format across providers.
No more “ClickUp calls it taskUpdated, Asana calls it task.changed.”
4. Guardrails
Rate limits, approval workflows, restricted fields.
Built in, not bolted on.
5. Audit Trails
Everything the agent does becomes a traceable log entry.
6. Provider Adapters
Thin mapping layer for each platform’s quirks.
Build your agent once. It works the same everywhere.
Why This Is Happening
Agent-native software is coming.
Linear already proved the model works.
The rest of the ecosystem will follow because the primitives are already there — they just need to be connected.
Right now every agent builder is solving this problem in isolation.
Eventually someone standardizes it.
We’re building it for Aleq anyway.
If it ends up being useful beyond that, great.
MAP ≠ MCP
MCP handles transport — how models call tools.
MAP handles semantics — how agents exist in workspaces.
Different layers. Both needed.
What Happens Next
We’re building this because we need it.
If you’re working on something similar and this resonates, reach out.
You’re probably hitting the same walls.
That’s it.
Back to building integrations.