Repository navigation
Question: what's the intended role of the platform/communication adapter layer? #294
Description
I've been following the repo and noticed two substantial PRs merge in the last few days — #191 (PlatformAdapter for GitHub/ADO/Planner) and #263 (CommunicationAdapter for Discussions/ADO/Teams/file log). Both look really well done, but I was having trouble placing them in the bigger picture, so I cloned the repo and asked the Mission Control squad that ships with it to help me understand.
The squad pointed me back to #8, where the ADO question came up in February and the answer at the time was:
Provider abstraction is prompt-level, not code-level. Abstracting providers means swapping command templates — not building a JavaScript runtime layer.
That framing made sense to me — agents using MCP tools or falling back to gh/az CLI directly, no SDK wrapper needed. But the adapter layer in #191 and #263 looks like it's doing something different. The squad noted the factories aren't wired up anywhere yet, which made me wonder if this is foundational work for something coming, or if the vision has shifted since February.
Just trying to understand the direction! @tamirdresher's research on ADO — the concept mapping, WIQL details — is clearly valuable regardless. I'm just curious where it's all headed. @bradygaster, happy to hear your thinking on the platform vision here.
Activity
github-actions commentedon Mar 9, 2026
📋 Assigned to Flight (Lead)
Issue: #294 — Question: what's the intended role of the platform/communication adapter layer?
Flight will pick this up in the next Copilot session.
github-actions commentedon Mar 9, 2026
📋 Assigned to CAPCOM (SDK Expert)
Issue: #294 — Question: what's the intended role of the platform/communication adapter layer?
CAPCOM will pick this up in the next Copilot session.
tamirdresher commentedon Mar 9, 2026
@EmmittJ Great question! I think it's important to clarify things.
The Short Answer:
The adapter layer in PRs #191 and #263 is not a shift away from the "prompt-level, not code-level" vision from issue #8. It's actually the enabler that makes that vision work at scale.
Here's how I see it:
When we say "prompt-level abstraction," what we mean is that agents shouldn't care about implementation details — they just issue commands and get structured responses. The adapters are the thin translation layer that makes that possible. They're not a "JavaScript runtime layer" in the sense of reinventing the CLI — they're wrappers that normalize outputs and handle platform quirks so the agent prompts stay clean and portable.
Think of it like this:
Without adapters:
Agent prompts have to say "if GitHub, run gh issue list | jq ...; if ADO, run az boards work-item list --wiql '...' | ConvertFrom-Json ..."
With adapters:
Agent prompts just say "list work items" and the adapter translates that to the right CLI call for the platform.
The key architectural decision is that adapters are thin — they don't replace az or gh, they call them. PlatformAdapter.listWorkItems() literally just runs Az boards query --wiql "..." or gh issue list --json ... under the hood. The value is in the interface contract (every platform speaks the same language) and error handling (failed CLI calls get normalized into standard error objects).
The "prompt-level" philosophy still holds: agents don't write platform-specific code, they use a unified interface. The adapters are infrastructure, not agent logic.
The vision hasn't shifted — we're just building the plumbing that makes cross-platform Squad actually work in production.
Happy to dig deeper if this doesn't fully answer your question!
EmmittJ commentedon Mar 9, 2026
Hmm, it seems like that could be handled via host's repo rather than in-process. For example, with Azure DevOps, you have a basic wiql builder which allows for basic customization. You will now have to handle every "I need x, y, and z field", or "sorting by x instead of y" because you are baking platform support into the sdk itself rather than letting the host's repo tell the agents how to perform those actions.
Another example, if you need to add support for gitlab, they call them "merge requests" instead of "pull requests", but you have the idea of a pull request baked into the sdk. Yes, they are the same, but the idea is the same. There is also an assumption here of pr based workflows where a lot of team are doing trunk-based dev.
There is also a lot missing in these abstractions as they assume folks are on the same platform for code/work items/etc. My team has repos/prs in GitHub and Work Items/Pipelines in Azure DevOps, or like my last job Azure DevOps and Jira. Peoples setups are crazy.and trying to account for them is going to be hard.
It feels like there is some abstraction here that allows users to "bring their own platform" as all of their setups are going to be unique.
tamirdresher commentedon Mar 9, 2026
you're raising exactly the right concern, and I actually agree with the direction you're pointing at.
The adapter code is a another step in the evolution towards the autonomous world, so the architecture is evolving as well. Here's how I see the longer-term picture (@bradygaster might not agree with me, i speak only for myself) :
Squad's real role is orchestrator and coordinator — it manages workflows, ceremonies, decisions, and team dynamics. For that, it needs a set of known capabilities ("list work items", "create PR", "post notification") that it can reason about. But how those capabilities are fulfilled should be pluggable.
The "bring your own platform" model is MCP/skills/plugins. When you configure Squad, you wire up your own MCP servers, skills, and plugins. Want GitHub + Jira? Bring a GitHub MCP and a Jira MCP/plugin. Want GitLab? Use a GitLab MCP. Squad doesn't need to know the implementation details — it just needs to know that "list work items" is a capability it can call.
Your point about mixed setups (GitHub repos + ADO work items + Jira) is exactly why this matters. The adapter layer can't realistically cover every combination. But MCP servers, skills, and plugins can — each one handles its own platform, and Squad orchestrates across them.
Where the adapters fit today: They're thin plumbing that makes certain common workflows (GitHub, ADO) smoother while MCP/skills/plugins tooling is still maturing (and the way they are used, i mean 6 months ago we only had MCPs, and until a month ago plugins werent a thing ).
As MCP servers and skills become more reliable and standardized, the adapters could shrink or disappear — replaced by whatever MCP servers, skills, and plugins the user has configured ot whatever new thing will come next.
So the vision from "prompt-level, not code-level" still holds. The adapters are a pragmatic bridge, not a permanent architecture. The real extensibility model is: Squad defines the what (workflows, capabilities), users bring the how (MCP servers, skills, plugins, CLI tools).
Appreciate you pushing on this — it's the kind of question that keeps the architecture honest.
github-actions commentedon Mar 13, 2026
📋 Assigned to CAPCOM (SDK Expert)
Issue: #294 — Question: what's the intended role of the platform/communication adapter layer?
CAPCOM will pick this up in the next Copilot session.
github-actions commentedon Mar 13, 2026
📋 Assigned to Flight (Lead)
Issue: #294 — Question: what's the intended role of the platform/communication adapter layer?
Flight will pick this up in the next Copilot session.
bradygaster commentedon Mar 20, 2026
Great discussion here — thanks @EmmittJ for the thoughtful question and @tamirdresher for the detailed responses.
To summarize the conclusion: the adapter layer is pragmatic bridge plumbing for common GitHub/ADO workflows while the MCP/skills/plugins ecosystem matures. The long-term model is 'bring your own platform' via MCP servers and plugins — Squad defines the what (workflows, capabilities), users bring the how.
EmmittJ's point about mixed setups (GitHub repos + ADO work items + Jira) is exactly right and validates the MCP-first direction. The adapters may shrink or disappear as MCP tooling standardizes.
Closing as answered — the architectural intent is documented in this thread.