Every modern security protocol, from multi-factor authentication loops to CAPTCHA challenges, exists to verify that an active human is driving the digital interaction. As engineering teams pivot from building simple chat interfaces to deploying autonomous, long-horizon agents, this human-centric foundation is fracturing beneath the surface. The identity stack built for interactive human sessions cannot support long-horizon agents without risking silent failure or security compromise.

The Human-Centric Assumption

To understand why autonomous workflows break, we must look at the primitives we inherited. Before OAuth 2.0, integrating third-party software required risky password sharing - giving an application your raw credentials and hoping it wouldn't abuse them.

OAuth replaced this with scoped token delegation: a user clicks "Connect," approves specific permissions, and an access token is issued to the application. It was an elegant architecture engineered for a world where humans sat at the center of every authorization boundary.

The implicit assumption of modern identity architecture: An active human user is always present at the consent boundary to resolve an expired session or unexpected re-authentication request.

Long-horizon agents violate this assumption at every axis. They execute unattended across systems, operate over days or weeks, scale horizontally into concurrent subtasks, and experience long periods of dormancy. When you stretch traditional authentication models across an autonomous runtime, the integration points do not just stop working. They fail quietly, causing data corruption and broken state machines.

Four Structural Break Points in Production

Break Point 1: The Dual-Authentication Gap

Every long-horizon agent operates across two distinct authentication layers that are completely disconnected from one another. The first is the primary orchestration layer, where the agent authenticates to its execution environment or hosting harness.

The second is the downstream resource layer: the actual APIs, databases, and enterprise platforms (like Gmail, Slack, or Salesforce) that the agent must manipulate to complete its objective.

Bridging this gap currently forces developers into a dangerous architectural compromise. To give an agent long-term autonomy, engineering teams either bake raw, long-lived API keys directly into the configuration space, or they trigger an initial OAuth flow and store the resulting tokens in an application database.

The first approach creates a massive credential exposure liability that compounds as the agent connects to more services. The second approach leaves the agent completely dependent on token lifecycles, scope management, and multi-agent async race conditions.

Break Point 2: The Execution Barrier

Consider an agent deployed to manage a multi-day enterprise vendor onboarding workflow. On Monday morning, it reads an approval trigger, pulls a contract from a secure drive, drafts an email, and updates an internal database. It then enters a waiting state, dormant until the vendor reviews and signs the paperwork. Three days later, the vendor responds. The agent wakes up to execute its next tool call, but the downstream access token expired exactly 60 minutes after it was issued.

In standard web applications, an expired access token is a minor hiccup; a refresh token is silently exchanged for a new access token inline with the user request. But if a refresh token has been invalidated by a corporate policy shift or provider-side rotation rule overnight, the application prompts a browser redirect for user re-authentication. A long-horizon agent running in a headless background worker cannot pause mid-reasoning to click a browser consent screen. Lacking a human-in-the-loop channel, the tool call fails. The agent doesn't necessarily crash loudly; instead, it frequently absorbs the error, retries indefinitely, or continues reasoning on stale context, falsely assuming an automated action succeeded when it actually failed.

Break Point 3: The Dormancy Disconnect

Continuous processes can manage token lifecycles inline because their refresh logic runs actively alongside execution loops. Intermittent agents, those designed to wake up only when a specific, long-delayed web-hook triggers, face a much harsher environment. During days of inactivity, no active process is monitoring or maintaining the connection between the agent harness and the target enterprise system.

While the agent sleeps, its refresh token sits dormant in a database. If the target platform enforces strict token lifespan limits or undergoes an unexpected credential revocation, the token expires long before the agent ever wakes up. The core failure here is architectural: the agent has no proactive visibility into its identity health. It discovers its credentials are dead only after it wakes up, constructs a complex plan, and executes its first critical tool call. Dealing with authentication errors during active runtime introduces massive state-recovery complexity to an already fragile reasoning loop.

Break Point 4: Concurrent Access vs. Refresh Token Rotation

To minimize the blast radius of stolen credentials, modern identity providers implement Refresh Token Rotation (RTR). Under an RTR framework, every time a refresh token is exchanged for a new access token, the old refresh token is immediately invalidated, and a single new refresh token is returned.

This security control turns catastrophic when an autonomous agent scales horizontally to complete a task.

If an agent spins up three concurrent subtasks to parse three different data sources simultaneously, all three subtasks may discover that their shared access token has expired at the exact same millisecond. They will all concurrently attempt to use the same shared refresh token to obtain a new access token. The first request to hit the identity provider wins, generating a brand new token family. The second and third requests arrive a millisecond later, presenting a refresh token that the provider just invalidated. The provider's automated abuse detection flags this as a replay attack, assumes a credential breach, and instantly revokes the entire token family. The agent's horizontal scaling mechanism effectively acts as a self-inflicted security breach, permanently cutting off system access until an administrator manually re-authenticates.

The Architecture for Unattended Autonomy

Resolving the identity mismatch requires moving past basic OAuth wrappers. Engineering teams must adopt a distinct architectural pattern: the Token-Mediating Gateway. This architecture completely decouples credential lifecycles from the agent's reasoning loop, enforcing absolute token blindness on the agent itself.

Under this pattern, an agent is never permitted to see, hold, or pass raw API keys or OAuth access tokens. When the agent decides to execute a tool call against an external system, it constructs a payload parameterized with a secure, abstract reference ID. The request is routed through an isolated infrastructure gateway that intercepts the call, reads the reference ID, fetches the valid token from a secure backchannel, injects it into the header, and passes the request to the downstream API.

This approach delivers two non-negotiable security and operational advantages for enterprise-grade agent stacks:

1. Hardened Prompt Injection Defenses: Because raw tokens never enter the agent's execution memory or context window, a successful prompt injection or malicious data-override attack cannot leak upstream infrastructure credentials. The agent cannot expose what it does not know.

2. Continuous Out-of-Band Maintenance: Token health is decoupled from agent activity. A background infrastructure service continually monitors, validates, and rotates credentials during periods of agent dormancy. If an identity provider enforces Refresh Token Rotation, concurrency locks are handled globally at the gateway layer before requests ever hit the provider.

If an automated recovery path fails entirely, the exception is intercepted by the platform layer. The gateway routes a structured re-authentication prompt directly to an administrative user dashboard without crashing the agent's internal state machine. The human handles the exception; the autonomous process remains intact.

The Boundaries of the Pattern

This token-blind architecture introduces undeniable operational overhead. For internal, single-session utility scripts or user-facing chat apps where an active human is explicitly driving every step of the execution, implementing an isolated, token-mediating gateway is clear engineering over-indexing. Traditional, short-lived OAuth access tokens managed directly by the client app remain the correct, most efficient choice for interactive workflows.

The Frontier: Isolation vs. Session State

While a Token-Mediating Gateway solves runtime exposure and concurrency races, it surfaces a foundational question at the boundary of infrastructure design: How do you securely maintain decryption keys for long-horizon tokens when an agent is entirely dormant?

If credentials are encrypted at rest and the decryption keys live only in active session memory, terminating the agent's compute instance to save costs over a three-day waiting window destroys the keys.

Storing long-lived tokens is a non-negotiable for the next few years. Resolving this session-key transport challenge without reintroducing massive security risks remains the core security engineering frontier in autonomous agent infrastructure.

Identity, authentication, and secure state maintenance are ultimately infrastructure problems, not model problems. Large language models can handle complex, long-horizon planning, but they cannot fix an invalidated OAuth token family at two in the morning. Building reliable, unattended automation requires an infrastructure built for the times when no one is watching.

For two years the default picture of an agent was a chat window with a loop in it. A goal goes in, tokens stream out, and the run ends when the context fills or the model loses the thread. That paradigm is ending. Agents are starting to carry entire workstreams: owning a migration, running a research sweep for a week, sitting on an inbox and acting when something arrives. They hold a goal across replanning cycles, spin up and right-size subtasks, move across multiple systems, and pull a human in only at genuine decision points, acting self-directed on accumulated context rather than waiting for the next instruction.

This is the long-horizon shift, and it has relocated the hard problem. Model capability is no longer the bottleneck. Today's models have the reasoning and coherence to hold a goal across many steps. The scaffolding around them is taking shape, but long-horizon exposes everything it hasn't solved yet. The scaffolding around them is another story. The harness is taking shape: orchestration, tool routing, context management, replanning. The primitives exist. But long-horizon exposes what short runs forgive. A harness built for a single session struggles to hold a goal across cycles, manage subtasks at scale, or know when to pull a human in. The infrastructure is further behind: persistent state, credential lifecycle, cost controls, environment coherence. The intelligence is there. The scaffolding that lets it run reliably, unattended, over days is where the work remains.

What we mean by long-horizon

Picture the difference this way. A chatbot is a sprint: one question, one answer, and it forgets you the moment the tab closes. A long-horizon agent is the colleague you hand a project to on Monday and check in with on Friday, and the work has moved.

That difference isn't about how long it runs. It's about the shape of the work: a goal made of many interdependent steps, where each builds on the last and an early wrong turn poisons everything downstream. That step structure, carried over a long duration, is the definition. It tends to play out over hours, days, or weeks, but the clock is a consequence of the work, not the thing that defines it. Long-horizon is a property of the task, not the runtime.

And it carries one demand short agents never face: the work outlives any single sitting. The agent has to hold the goal, and the context behind it, across replanning, across failure, and across idle time. Idle time is the hard one. Nearly every real long-horizon task has to go dormant at some point, waiting on an approval, a dependency, a human, then wake on the right signal and pick up exactly where it left off without dropping the thread. That capability, persistent agency and memory across the gaps, is something long-horizon work requires and that almost nobody has truly solved.

Two examples of such workflows: First, an agentic project manager plans the work, runs it across half a dozen systems, then sits for hours or days waiting on an approval or external event before resuming. Second, a personal assistant that lives alongside you and acts the moment something needs doing. Neither runs the whole time. Both have to stay coherent while nothing is happening.

Long-horizon vs. long-running

Right now "long-running" and "long-horizon" get used interchangeably. That hides a distinction worth making.

Our view: long-horizon is the umbrella

Long-running describes a single process: one engagement that stays alive, from start to finish, driven to completion in one continuous run.

Long-horizon is the umbrella above it. It's a goal pursued across many tasks and subtasks over time: some long-running processes doing the deep work, some short bursts knocking out a subtask, each spun up when it's needed against one persistent goal. What makes the whole thing long-horizon isn't that any single process runs long. It's that the engagement doesn't run straight through. It carries intermittency: idle stretches between the pieces, where the agent sits dormant through an approval, a dependency, an overnight gap, then wakes on a signal and resumes exactly where it left off. Intermittency, interdependent steps, long duration: carry those and you have a long-horizon agent, whether the pieces inside it run for two minutes or four hours.

That idle time is where things often break today. The model can reason across the steps. The infrastructure to hold a goal, a credential, and a context alive across days of dormancy still needs to be built. The single continuous run is a solved problem. The umbrella case, project-scale work and always-on assistants, is the unsolved one. That gap is where the next era of agent infrastructure gets built.

Entering the Long-Horizon Era

Most of the failure modes are already on the table. Context that rots, state that vanishes, credentials that die mid-run, costs that spiral, fleets that collide, agents that declare themselves done at thirty percent. They are reality today, and most are still unsolved. Stretch the same agent across idle time and a project-shaped goal, and every one of them gets harder.

They are structural infrastructure problems, not model problems, and solving them is where we spend our time at Keska Labs. Six areas, each getting its own deep dive in this series:

1. Authentication. OAuth assumes a human present at the consent boundary. A long-horizon agent violates that assumption on every axis: no human at consent, concurrent access, indefinite runtime. Continuous agents need credentials kept alive mid-run; intermittent ones need a background service that keeps them alive while nothing is running. We've written this up separately, and a dedicated deep dive on the token-lifecycle gap is next.

2. User experience. Setting up an agent to run for a week, and staying in the loop without babysitting it, is still a developer's job. For long-horizon work to reach non-technical operators, the experience of defining the work, watching it, and stepping in at the right moment has to be a product surface, not a config file.

3. Security. A long-running agent with cloud access and shell execution is a much larger attack surface than a chat session. Credentials reachable from the sandbox where model-generated code runs, memory that can be poisoned across sessions, permissions that don't scope down per subtask: these get harder, not easier, as the agent persists.

4. Multiple environments. Real long-horizon agents don't live in one place. They move across sandboxes, machines, and cloud runtimes, and they exist across many authenticated services at once. At eight or more concurrent connections on independent schedules, something is always about to expire or drift. Coherence across environments becomes its own problem.

5. Cost and token consumption. A multi-day run with a frontier model can quietly burn a week's budget in an afternoon. Part of the answer is budgets and circuit breakers; part of it is architectural: routing the right work to smaller, cheaper models and reserving the frontier model for the steps that actually need it. Most of a long horizon doesn't need the biggest brain.

6. Observability. An agent runs for six hours, makes forty tool calls, and produces a wrong answer. Without a structured trace of what it did and why, you cannot tell whether it hallucinated, hit a bad API response, or was handed the wrong goal at the start. Auditing autonomous activity after the fact is a real human-time problem, and right now most teams are solving it by scrolling logs and hoping they catch what matters

Where this goes?

The gap between a chat window and an agent you can leave running for a week isn't in the model. It's in the state, sessions, credentials, and coordination wrapped around it, and every one of those gets harder the moment the agent has to survive idle time.

That gap is what we build at Keska Labs. This is the first post in a series, and each focus area above gets its own deep dive. We start with authentication, the problem we've thought hardest about and the one that quietly kills more unattended agents than any other.

Quick recap from the first post: Agent Skill Sync is a small VS Code / Cursor extension that pulls Cursor rules and skill packages from a GitHub repo (or a custom registry) and drops them where Cursor actually looks, .cursor/rules and .cursor/skills. Free on Open VSX: KeskaLabsAB / agent-skill-sync.

The plugin we showed off in the last post nailed the boring half: getting curated skills out of git and into the editor without a copy-paste ceremony. Then the catalog grew. And the moment a teammate opened the panel, blinked at twenty-something skills, and asked “okay… which of these do I actually want?”, we knew the next problem to solve.

This post is about that. Discovery. Less scrolling, more “oh, that one.”

First, the unsexy bit

Before we could put a recommender on top, the foundation had to behave. A quiet polish pass cleaned up two things you’ll notice mostly because they stopped annoying you:

• First-run reliability: the welcome / setup prompt no longer flickers, double-fires, or leaves you staring at a blank panel on a fresh install.

• Browse tree expand/collapse: nested folders now toggle the way you expect them to. Subtle, deeply annoying when it was wrong.

Onward.

A Recommended tab, finally

We added a third tab to the Skill Manager, next to Manage and Browse, called Recommended. It looks at your workspace and ranks the catalog for you.

“Looks at your workspace” isn’t magic. It reads the ordinary tells:

• which languages the repo uses,

• what’s in package.json / pyproject.toml / Cargo.toml / go.mod (your dependencies),

• a few path markers (Dockerfiles, monorepo configs, etc.),

• which VS Code / Cursor extensions you have installed,

• and AGENTS.md if you keep one.

Each catalog skill can declare triggers in its SKILL.md (languages, dependencies, files, keywords). The tab cross-references the two and surfaces the matches with a small chip telling you why, “Keywords matched AGENTS.md [rest, api, endpoint],” that kind of thing. No surprises, no black box.

We improved Browse at the same time: every node in the repository tree got a checkbox, so you can enable a skill straight from the tree without round-tripping through Manage. Skill packages and standalone rules are treated separately, so enabling a package doesn't accidentally toggle individual files inside it.

The Manage tab. Toggling a skill writes the whole package under .cursor/skills/<name>/. The SKILL.md on the right is what feeds the recommender: triggers.dependencies, triggers.files, triggers.keywords.

Then we let an LLM rank them

Heuristic matching is great until the catalog gets opinionated and your repo gets messy. So the Recommended tab now tries an LLM first and only falls back to keyword matching if no model is available. The chain in this exact order is:

1. vscode.lm: VS Code’s Language Model API. If you have GitHub Copilot installed in VS Code, this is already wired up. (Heads up: Cursor doesn’t expose its built-in models through vscode.lm yet, so Cursor users land on step 2 or further.)

2. Cursor SDK: if you’ve set a key.

3. OpenAI: if you’ve set a key.

4. Anthropic: if you’ve set a key.

5. Heuristic: the original signal-matching logic. We label the result with a HEURISTIC badge so you’re never wondering which mode you’re in.

Keys are optional and stored in VS Code Secret Storage, not your settings.json. Set them with Skill Sync: Set OpenAI Recommendation Key (and friends), nuke them with Clear Recommendation API Keys. We don’t see them, we don’t want them.

Results are cached per-workspace with a TTL so the panel doesn’t hit a model every time you blink. Hit Refresh to bypass the cache when something obviously changed.

Ask the Agent: keep the smart part inside Cursor

Now the part Cursor users will care about most.

If you don’t want to wire up an API key, you don’t have to. Click Ask the Agent and the extension does three things:

1. Builds a context-rich prompt. Your workspace fingerprint (languages, deps, monorepo flag, AGENTS.md presence), the current synced catalog candidates, and the skills you’ve already enabled.

2. Opens it pre-filled in Cursor’s composer, via Cursor’s own prompt deeplink. You see a Create chat with prompt sheet first: review, then Create Chat. (We also copy the same prompt to your clipboard, just in case.)

3. Routes the request to a bundled subagent, agents/skill-recommender.md, which is shipped with the repo as a Cursor Plugin. Enable the plugin once and the subagent shows up like any other agent.

The result: no API key, no LLM cost, and the model that already lives inside Cursor (the one you’re paying for anyway) does the ranking, with the context that only the extension can collect.

Recommended on the left, Ask the Agent on the right. The prompt isn’t a one-liner, it includes the workspace fingerprint and the live catalog so the agent has something to reason about.

A small but important detail: oversized catalogs are automatically trimmed to fit Cursor’s deeplink size budget, so this doesn’t silently break on big skills repos.

A new file you didn’t know you wanted: catalog.json

Whenever you sync or browse, the extension now writes a tiny manifest at:

.cursor/skill-sync/catalog.json

Metadata only, no skill bodies. It’s the file the bundled subagent (and any tooling you build on top) reads to know what’s actually in your team catalog right now. If you’ve ever wanted “the agent should know which skills are available without me copy-pasting,” this is that.

The plugin layout follows the official Cursor plugin spec: manifest at .cursor-plugin/plugin.json, agent files in agents/ next to it. Two paths, because that's what Cursor requires, not because we like extra folders.

How to try it (the short path)

1. Install Agent Skill Sync (currently 0.7.0) from Open VSX, or the VS Code Marketplace.

2. Connect a skills repo (owner/repo): yours, your team’s, or play with a public one.

3. Open the Skills sidebar (Ctrl+Alt+S / Cmd+Alt+S) and click the Recommended tab.

4. Either:

   • Don’t configure anything → you get heuristic ranking (badge says HEURISTIC), or

   • Hit Ask the Agent → Cursor’s composer opens with the prompt prefilled, no key needed (works best with the bundled skill-recommender plugin enabled), or

   • Set a provider key via Skill Sync: Set … Recommendation Key → ranking goes live with that model on every refresh.

Toggle what looks useful. Files land under .cursor/rules and .cursor/skills like before. Done.

Why this matters more than “a new tab”

Curated skill repositories are starting to look a lot like internal package registries: versioned, reviewed, owned by the platform team. The next problem after “how do I get them into the editor” has always been: which ones, for this codebase, today?

We don’t think the answer is a longer onboarding doc. The answer is the editor noticing what you’re working on and saying so. The first cut of that is the dumb-but-honest version: signal matching with reason chips. The second cut hands the same context to a model, and if no model’s around, to your own Cursor agent in one click.

If something’s weird, open an issue. If it just works, enable a skill nobody on the team has tried yet and tell us if the ranking was right.

Keska Labs

At Keska Labs, we're betting on a different layer of the stack.

Routing every minor user request through a giant cloud model isn't strategy. It's overhead. The shift that actually matters in 2026 is happening on the laptop on your desk and the phone in your pocket: small, capable models running locally, fast enough to feel instant and cheap enough to feel free.

We believe the future belongs to Small Language Models (SLMs) and Tiny Language Models (TLMs). Here is why we are betting on small, and why it changes the math for everything we build.

Small Models Got Quietly Great

A couple of years ago, a 3-billion-parameter model was mostly a toy. It would lose context quickly and struggle to follow basic logical instructions.

That stopped being true. Carefully filtered training data, distillation from larger teacher models, and architectural improvements have turned sub-10-billion-parameter models into serious production tools.

The current lineup tells the story. Microsoft's Phi-4-mini (3.8B) matches 8B-class models on math and reasoning benchmarks². Google's Gemma 3 (4B) is competitive with last year's 27B flagship and ships with vision and 128K context³. Alibaba's Qwen3 (8B) lets you toggle between fast inference and a slower "thinking" mode for harder problems. Meta's Llama 3.2 (3B) is the open-weight default for mobile.

These models are not trying to be omniscient. Long-tail factual recall is genuinely weak. What they are excellent at is the work most software actually needs: structured output, instruction-following, classification, extraction, and bounded reasoning within a known domain.

Add modern quantization, which compresses a model's memory footprint with only modest loss in quality on these workloads, and an 8-billion-parameter model fits comfortably in around 4.5GB of RAM.

The Hardware Math: Why Now?

There is a lingering assumption that local AI requires a water-cooled, custom-built workstation with expensive GPUs. That stopped being true sometime in 2024, and by 2026 the math has flipped: a meaningful share of the devices already in people's hands can run a useful model locally, today.

The shift was driven by silicon. Apple's Neural Engine, Qualcomm's Hexagon NPU, Intel and AMD's NPUs in Copilot+ PCs, and the unified-memory architecture across Apple Silicon all moved the baseline at the same time. The result is two clear tiers worth thinking about.

The 2B Threshold (~2GB Active RAM): A fast, quantized 2-billion-parameter model fits in roughly 2GB of working memory. That covers every iPhone 15 Pro and iPhone 16 series device, plus the Pixel 8 Pro and up, plus most Snapdragon 8 Gen 3 and Gen 5 Android flagships. Apple alone reports more than 2.5 billion active devices in its installed base⁴; the share of those running on hardware capable of on-device AI grows every quarter as the replacement cycle plays out.

The 4B Sweet Spot (~3.5GB to 4GB Active RAM): This is the target for professional workflows on a laptop, and it requires roughly 16GB of total system memory to leave headroom for the OS, the browser, and everything else a knowledge worker actually has open. As of the March 2026 refresh, every MacBook ships with at least 16GB. AI PCs, which include a dedicated NPU, are forecasted⁵ to make up 55% of all PC shipments in 2026, up from 31% in 2025. Between the two, a substantial and rapidly growing share of the professional installed base can run a 4B model locally without sending it anywhere.

Local first is not a theoretical "five year demographic bet" from now.

What Local Actual Buys You

Take a workload we at Keska Labs focused on: lowering the cost of Knowledge Graph construction. Extracting entities and relationships from large volumes of data and keeping it up to date, simply did not make sense. With 350 million parameters Liquid AI models this is rapidly becoming reality

This is exactly the kind of work where the cloud-first instinct is wrong. Not because frontier models are bad at it (they are very good), but because the workload is repetitive, structured, and high-volume, and routing every record through a cloud API gives up three things at once.

1. No network latency. The data is already on the device that produced it. Removing the round-trip turns extraction from a request-response operation into something that feels like local file processing. No spinners, no rate limits, no degraded behavior on a flaky connection.

2. Compliance by default. For regulated workloads (sensitive complaints, proprietary code, health data, anything covered by GDPR data-residency rules) the data never leaves the device, which collapses a meaningful share of the compliance surface. Local inference is not the whole answer to privacy, but it removes the largest exfiltration vector by construction.

3. Costs that stop scaling with usage. Inference happens on hardware the user already owns and powers. The marginal cost of the millionth extraction is the same as the first: roughly nothing. You still pay for fine-tuning, evaluation, and model distribution, but the per-request cloud bill that scales linearly with adoption disappears.

None of this comes free. Local deployment trades cloud cost for engineering cost: model evaluation across a long tail of customer hardware, an update pipeline for new model versions, drift management as customer data evolves, and a cloud fallback for the requests that genuinely need a frontier model.

The Next 5 Years: The Local Router

As we look toward 2030, the novelty of typing into a chat interface will fade. It was where most people first met AI. What comes next is the model disappearing into the product, and the competitive layer of software moving with it.

Intelligence will be layered. The device in your hand or on your desk will run a small model that is always available, handling the steady, high-volume work that makes up most software interactions: classifying inputs, parsing structure, drafting replies, fetching context from local files, routing requests. The cloud will still be there, and for the work that genuinely needs it (novel reasoning, broad world knowledge, long-context synthesis) it will remain the right answer. What changes is the default. Cloud-first becomes cloud-when-needed, and the routing decision becomes a deliberate one.

We call this the local router. It is the architecture we expect a meaningful share of serious software to converge on by the end of the decade.

For builders, the implication is concrete. The advantage in the next five years will not belong to the teams routing every request to the cloud out of habit. It will belong to the teams who decide deliberately, request by request, where intelligence should live. That is harder than picking an API. It is also where the leverage is.

That is the bet we are making

¹ Tech AI spending may approach 700BN USD this year

² Microsoft Phi-4-mini Technical Report

³ Gemma 3 Technical Report

⁴ Apple reports first quarter results

⁵ Gartner Says AI PCs Will Represent 31% of Worldwide PC Market by the End of 2025

You can grab it on the Open VSX Registry: KeskaLabsAB / agent-skill-sync.

What it does (without the brochure voice)

You connect a source—usually owner/repo on GitHub. The Skill Manager opens in the sidebar: Manage for what’s on in this workspace, Browse if you want to poke around the tree like a civilized person. There’s also catalog search when you’d rather type “api docs” than click five folders.

Content-wise we support the boring-but-useful stuff:

• Single-file rules (.mdc, .md, etc.) → synced as Cursor-style rules.

• Skill packages—folders with a SKILL.md in the agentskills.io shape → whole directory lands under .cursor/skills/<name>/ when you flip it on.

So your “skills repo” can be a real repo: versioned, reviewed, boring in a good way.

Why we bothered publishing it

Internally we were already curating skills in git—security checklists, PR templates, little opinionated prompts that make agents less chaotic. The missing piece was getting that into the editor without ceremony. We got tired of documenting the manual steps for every new machine and every new teammate.

Publishing it was basically: if we need this, someone else might too—and Open VSX is a fine home for tooling that isn’t married to a single storefront. Same extension, same idea: your skills live in source control; the editor just syncs what you opted into.

How to use it (the short path)

1. Install from Open VSX: agent-skill-sync.

2. Open the Skills view (or run the command palette entry for managing skills—your muscle memory may vary).

3. Sign in to GitHub if the repo is private; we use the normal provider flow, nothing exotic.

4. Point it at your repo (owner/repo) or switch to registry mode if that’s your setup.

5. On Manage, toggle what you want. Sync runs in the background or when you hit refresh—either way, files show up under .cursor/rules and .cursor/skills in the workspace you’re in.

Keyboard shortcut people: Ctrl+Alt+S (Windows/Linux) or Cmd+Alt+S (macOS) focuses the sidebar, unless you’ve remapped it to something weirder. We don’t judge.

Settings are the usual skillSync.* keys—source mode, repo string, registry URL, categories, opted-in list. If you live in JSON settings, you already know where to click.

Fine print, but make it fashion

GitHub traffic uses your session. We’re not shipping analytics in the extension to tell you how often you toggled “API documentation.” Skills land in your workspace paths; nothing magic happens in our cloud because there isn’t one for this.

If something breaks, open an issue on github.com/keska-labs/enterprise-skills. If it doesn’t break, enjoy the part where your agent actually reads the same files as the rest of the team.

— Keska Labs