Skip to main content

You don't need to build your own agent harness

Building an agent sounds straightforward until you actually start. Before you write a single line of business logic, you're already deep in infrastructure decisions: How do you manage context across multiple turns? How do you orchestrate tool calls? How do you handle model routing, MCP server integration, permissions, failure modes, and safety boundaries? By the time you've answered all those questions, you've quietly built a small platform — and you haven't shipped anything yet.

This is the tax that every team building agentic applications has been paying.

Until now...

Meet the GitHub Copilot SDK

GitHub launched the Copilot SDK in technical preview in January 2026, and its core value proposition is refreshingly direct: stop building the harness, start building your product.

The SDK gives you programmatic access to the same production-tested execution loop that powers GitHub Copilot CLI. That means the planning, tool invocation, multi-turn context management, and runtime that GitHub has been running at scale — available in your application, in your language, on day one.

The SDK currently supports Node.js, Python, Go, Java and .NET.

What you get out of the box

When you embed the Copilot SDK, you're not getting a thin wrapper around a model API. You're getting an agent runtime. Specifically:

  • A production-grade execution loop — the same battle-tested engine behind Copilot CLI, handling the plan → act → observe cycle for you
  • Tool invocation — file system operations, Git operations, web requests, and shell commands, all wired up and ready to use
  • MCP server integration — native Model Context Protocol support so your agent can reach any context or capability you need
  • Multi-model routing — flexible model selection across all models available via Copilot CLI
  • Authentication and session management — GitHub handles it; you don't have to
  • Streaming — real-time responses out of the box

You can also customize: enable or disable specific tools, define custom agents and skills, add your own logic, and bring your own API keys (BYOK) if you prefer not to use GitHub auth.

The real value: skip the platform, ship the product

Here's what makes this genuinely different from rolling your own agentic stack.

When you build an agent from scratch, you're making dozens of low-level decisions that aren't really your product. You're choosing an orchestration library, wiring up tool loops, designing a context management strategy, thinking through retry logic and error handling, figuring out how to surface permissions to users safely. None of that is differentiated. None of it is why your users will choose you.

The Copilot SDK collapses all of that into a single dependency. As GitHub put it when they launched: "Instead of wiring your own planner, tool loop, and runtime, you can embed that agentic loop directly into your application and build on top of it."

That's not just a convenience — it's a fundamental shift in where developer effort goes.

Looking for some inspiration?

The use cases span a wide range. Some examples:

  • GUIs with embedded AI workflows — add an intelligent assistant to any desktop or web app without managing the agent infrastructure behind it
  • Personal productivity tools — automate repetitive workflows with an agent that can read files, run commands, and take action on your behalf
  • Enterprise internal agents — embed Copilot capabilities into internal tooling, CI/CD pipelines, or custom developer portals
  • Multi-agent systems — the SDK integrates with frameworks like Microsoft Agent Framework, so you can compose Copilot agents with agents from other providers in sequential, concurrent, or handoff workflows

A practical starting point

Getting started is intentionally minimal.

In Python:

In .NET:

Two dozen lines of infrastructure work — replaced by a few.

What's coming in this series

I hope that you are ready for some more. As this post is only the first in a series on building with the GitHub Copilot SDK. In the posts ahead, I've planned to talk about:

  • Getting started — setting up the SDK, authentication, and your first working agent
  • Session management — how you can create, manage, persist and resume session
  • Deployment architecture — deployment options and when to choose what
  • Tool use and customization — enabling, disabling, and extending the built-in tools
  • Building a real workflow — a practical walkthrough of an end-to-end use case
  • MCP integration — connecting your agent to external context and services
  • Multi-agent patterns — composing Copilot agents with other providers

More information

Harness engineering for coding agent users

Cursor's $60 billion bet is on the harness, not the model - The New Stack

Labels:

Popular posts from this blog

Podman– Command execution failed with exit code 125

After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...
Read more

Cache stampede: when our cache turned against us

While investigating some performance issues, we ran into an ASP.NET Core API that cached a fairly expensive aggregation query for 60 seconds. Under normal load, that was fine: one request rebuilds the cache, everyone else reads from it. Under peak load, dozens of requests would arrive in that same expiry window, all see a cache miss, and all fire the same expensive query in parallel. The database didn't like that. That was the moment when our caching layer stopped helping and started hurting. A burst of requests comes in at the same time, all miss the cache, and all go hammer the database or the downstream API at once. That's a cache stampede . The cache was supposed to protect our backend, and for a few hundred milliseconds it did the opposite. Why this happens IMemoryCache.GetOrCreate (and its async sibling) looks like it protects you, but it doesn't add any locking on its own. Look at the naive version: public async Task<Report> GetReportAsync(string key) ...
Read more

A complex system designed from scratch never works

A few years ago, I worked as an architect on a big mainframe rewrite. I still count it as one of my failures. Not because the technology was wrong, but because I couldn't convince the management team to simplify the approach. Years later, the organization is still struggling to get the new system up and running. I left the project at the time, because I couldn't put my name behind an approach that would take very long and cost a lot of money without a working system to show for it along the way. Gall’s Law That memory keeps coming back to me, because it's a textbook case of Gall's Law playing out in real life. Gall's Law , from John Gall's Systemantics , states it plainly: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works, and it cannot be patched to make it work. You have to start over with a simple system that works. What does that mean in practice,...
Read more