---
title: Why our integrated coding agent ships with an SDK
description: Jaspers Terminal's coding agent builds the tools a user's research needs. The SDK gives it the context to do that, and takes credentials, storage, rendering, and the assistant's contract off its plate.
date: 2026-10-13
author: Seth Johnson
---

# Why our integrated coding agent ships with an SDK

We ship a coding agent inside [Jaspers Terminal](https://github.com/JaspersAI/terminal) to build the tools a user's research needs. We also ship [an SDK](https://www.npmjs.com/package/@jaspers-ai/sdk) that gives the agent less to figure out.

That second part is important. Every new data connection could become a small software project, with its own decisions about credentials, storage, rendering, and how everything fits together. Our SDK settles many of those decisions before the agent starts writing code.

![The SDK drawn as an assembly sheet: the parts a plugin declares, what its backend reaches through ctx, what a view reaches through hooks, the pure helpers, and the process boundary to the app behind them](/uploads/blog/why-our-integrated-coding-agent-ships-with-an-sdk/figure-1.svg)

## A request, and what is already there

Take a request like "chart the 10-year Treasury yield from FRED." If the Terminal can't find a suitable plugin, it hands the request to the coding agent. The agent needs to understand FRED's API, fetch the right series, and return usable data. The Terminal already has a chart, a place to put it, and a way to collect the user's API key.

The SDK lets the agent work within that existing structure. It defines a source, declares its inputs and the hosts it needs to reach, and writes the function that returns the data. For this request, that can be enough. The built-in chart can display the results.

## Two related jobs

We think about this as two related jobs: **providing coding context** and **reducing the complexity space**.

The context is concrete. The builder gets the SDK reference, backend type definitions, a tutorial, and complete plugin templates. These come from the same files developers read, bundled with the app. The agent has examples of working plugins and the actual signatures of the methods it can call.

![What the builder is given: the SDK reference, type definitions, tutorial, and plugin templates](/uploads/blog/why-our-integrated-coding-agent-ships-with-an-sdk/figure-2.svg)

That tells it how to use what we've built. The SDK and runtime then reduce how much it needs to build itself.

Credentials have an established flow. Sources have a standard interface. Views have hooks for reading data and updating panel state. A plugin that needs the user's model can call it through the app. These are shared facilities, so the agent doesn't have to implement another version for each request.

The complexity still exists; we take responsibility for it in the Terminal. What gets smaller is the problem handed to the coding agent.

## What is left to get right

There's plenty left to get right. A FRED plugin still needs to select the correct series, preserve units, and handle missing observations. Giving the agent a standard way to fetch and display data leaves it with fewer unrelated decisions competing for attention.

## A contract the assistant understands

The SDK also defines how the assistant uses the finished tool. A custom view declares the state the assistant can change and publishes information about what it shows. The assistant can then update its inputs and read its output through that contract. Those decisions are part of building the view, so the resulting plugin arrives with an interface the assistant understands.

## Feedback along the way

The builder gets feedback along the way. The app rebuilds its edits and reports errors. Schemas check inputs and panel state. The builder is instructed to run completed sources with real arguments and inspect the results. Those checks help catch integration mistakes; whether the data answers the research question still requires judgment.

![The builder's feedback loop: the shell installed with the user's yes, each edit rebuilt by the watcher, check_plugin and run_source answering, errors routed back to edit_file, schemas on inputs and panel state, and the finished plugin left as an ordinary folder under ~/Jaspers/plugins](/uploads/blog/why-our-integrated-coding-agent-ships-with-an-sdk/figure-3.svg)

Once built, the plugin stays in the user's Terminal as an ordinary folder they can inspect, edit, or share. The next time they need that series, the tool is already there.