The Agent-Agnostic Context Layer: Tools, Memory and Skills Behind One URL

Move the working context outside the session

Suppose Claude Code investigates a release failure on a laptop, then a teammate continues in Cursor inside a fresh development environment. The second agent needs access to the issue tracker, the team's explanation of the release process and the procedure for checking a failed deployment. Reconnecting the tracker alone leaves two of those dependencies behind.

Design the shared layer around that handoff. Keep durable decisions, procedures and system connections outside the first agent's session. Leave its conversation, temporary hypotheses and unfinished command state with the harness unless someone deliberately records a useful result. This makes the handoff inspectable: the next agent can identify which decision it retrieved and which live system it queried.

That is an architectural recommendation, rather than a guarantee of identical answers. Changing agents can change reasoning, approvals and tool selection even when both receive the same information. The useful promise is that replacing the client does not require rebuilding the team's context and connections.

Give tools, memories and skills different contracts

The MCP tools specification defines discovery through tools/list and invocation through tools/call, with input schemas describing arguments. Use that shared interface for operations, but preserve the meaning of what each operation returns:

• Tools reach current systems. A deployment-status query should report its upstream result, including failure.
• Memories preserve recorded observations or decisions. A note about last month's rollback is evidence to reconsider against today's deployment state.
• Skills describe procedures. A release-investigation skill tells the agent which evidence to collect and when to ask a human.

The Agent Skills specification defines a directory containing SKILL.md, with YAML frontmatter and a Markdown body. For example, a directory named release-investigation could contain:

---
name: release-investigation
description: Investigate failed releases using deployment status and linked issues.
---
Read the failed deployment and its linked issue.
Compare the observed failure with recorded release decisions.
Report the evidence and proposed next action.
Ask for approval before changing deployment state.

Serving that text remotely makes it retrievable. Native installation or activation remains an integration task for each client. Keep tool references understandable without a particular vendor's slash commands; writing portable skills covers the file format in more detail.

Keep the endpoint stable and adapt the client config

A shared service still needs a small client-specific connection configuration. The examples below use https://context.example.com/mcp as a placeholder for your remote HTTP endpoint; they do not create a server. Claude Code's documented command syntax is:

claude mcp add --transport http company-context https://context.example.com/mcp

For a server offering OAuth, open /mcp in an interactive Claude Code session and complete sign-in. Adding the URL alone does not establish that the authenticated service is usable.

Cursor's documentation uses mcpServers with a url field for remote services. Its project-level configuration belongs in .cursor/mcp.json:

{
  "mcpServers": {
    "company-context": {
      "url": "https://context.example.com/mcp"
    }
  }
}

Complete the server's required authentication separately. Sharing this URL does not mean sharing a credential: give each agent its own authorization. Keep provider tokens out of the shared project file. These two adapters point at the same service while leaving the service's memory paths and tool contracts independent of either editor.

Load an index first and retrieve the working set

Putting everything behind one address should not put everything into every prompt. Anthropic's context-engineering guidance describes keeping lightweight references and retrieving detail when needed. The Agent Skills specification similarly separates skill metadata, activated instructions and supporting resources.

For the release handoff, start with a compact catalog: available source names, memory locations and skill descriptions. Load the release-investigation procedure when the task calls for it. Retrieve the relevant rollback decision, then query current deployment status. Avoid attaching unrelated customer notes or the full history of previous incidents.

Make retrieval behavior part of your architecture contract. Require bounded result sizes, identifiable records and explicit errors. Distinguish an empty search result from a failed search: only the first supports saying that no matching memory was found. A small bootstrap and a searchable store give an ephemeral agent a route to context without requiring it to carry the whole workspace. Session-start context budgets examines that loading decision.

Enforce one policy boundary across different kinds of state

Unifying access concentrates responsibility. The layer must distinguish the calling person, workspace, agent credential and requested operation before it returns context or forwards a tool call. In an OAuth deployment, the MCP authorization specification requires servers to validate that access tokens target their own resources. A token accepted at the endpoint is still only the beginning of the authorization decision.

Specify independent permissions for reading context, changing memory and writing to connected systems. The release investigator may need to read a rollback decision without permission to rewrite it or trigger a deployment. Enforce those checks at execution time; hiding a tool from discovery cannot substitute for rejecting an unauthorized call.

Require personal and shared memory to have explicit ownership. A skill containing instructions to deploy must not grant deployment access. Likewise, a recalled incident note must remain recorded data rather than gaining authority because it arrived from a familiar endpoint. Review the content and the permissions separately.

Finally, define the operational evidence you need: who changed a memory, which source served a tool result, when revocation takes effect and what clients see during an outage. Central access creates a dependency shared by retrieval and tool use. Test those failures together, and avoid treating yesterday's remembered status as a successful live query.

Where SPYN3 fits in this architecture

SPYN3 exposes connected systems through one workspace endpoint, https://api.spyn3.com/agent/mcp, and reveals source tools on demand. Upstream credentials stay in the workspace; agents hold a SPYN3 key or OAuth token. An admin can enable Memory & skills, off by default, to expose personal and workspace memories, skills and notes through MCP context tools. Reading needs call:tools; memory writes need separate write:memory permission. Any MCP client can use these tools. Automatic memory uses a lifecycle-hook plugin for Claude Code and Codex; it is not implied for every client.

Prove the handoff with a fresh agent

Use an acceptance exercise that crosses all three assets. Prepare a fictional failed release, a shared decision explaining why automatic rollback was disabled and a skill describing the investigation. Give two clients equivalent read access with separate credentials, then run the following checks:

1. In the first client, retrieve the decision, load the skill and query the release's current status. Record the source and memory references it actually used.
2. Start the second client without copying the chat transcript. Ask the same investigation question and verify that it retrieves the same shared decision and procedure.
3. Change the fictional live status. Confirm that the second client obtains the update through a tool rather than presenting remembered status as current.
4. Attempt a memory change and a deployment write with the read credential. Verify that both are denied, even if the procedure mentions those operations.
5. Revoke one credential and repeat a call from that client. Check the rejection and audit record while the other client's authorized access continues.

Judge portability by accessible evidence and enforced permissions, rather than matching prose. If both clients can retrieve the required context, interpret failures and respect the same boundaries, the service contract survives an agent change. For broader rollout, continue with one scoped key per agent.