Managing Agent Context via API

Count's AI agent follows instructions outlined in agent context, which can be set at the workspace, project, or connection level.

Context can be manually edited in the Count UI. But it's also exposed through Count's API (GET/PATCH on workspace, project, and connection resources), which means it can be read and written programmatically, just like any other piece of config.

API examples

Below are some example Python scripts for interacting with the agent context via API. More API code examples including cURL and Typescript versions of the below can be found in the API reference under the API+MCP tab in your workspace settings.

Get workspace context

import requests

COUNT_API_KEY = '...'

headers = {
    'Authorization': f'Bearer {COUNT_API_KEY}',
    'Content-Type': 'application/json',
}

response = requests.request(
    "GET",
    "https://api.eu.count.co/v1/workspaces",
    headers=headers,
)

print(response.json()["result"]["agent_context"])

Patch workspace context

import requests

COUNT_API_KEY = '...'

headers = {
    'Authorization': f'Bearer {COUNT_API_KEY}',
    'Content-Type': 'application/json',
}

json = {
    'agent_context': 'Our company uses fiscal quarters starting in April...'
}

response = requests.request(
    "PATCH",
    "https://api.eu.count.co/v1/workspaces",
    headers=headers,
    json=json
)

GET project context

import requests

COUNT_API_KEY = '...'

headers = {
    'Authorization': f'Bearer {COUNT_API_KEY}',
    'Content-Type': 'application/json',
}

response = requests.request(
    "GET",
    "https://api.eu.count.co/v1/projects/project_key",
    headers=headers,
)

print(response.json()["result"]["agent_context"])

PATCH project context

import requests

COUNT_API_KEY = '...'

headers = {
    'Authorization': f'Bearer {COUNT_API_KEY}',
    'Content-Type': 'application/json',
}

json = {
    'agent_context': 'This project contains our retail sales data...'
}

response = requests.request(
    "PATCH",
    "https://api.eu.count.co/v1/projects/project_key",
    headers=headers,
    json=json
)

GET Connection context

import requests

COUNT_API_KEY = '...'

headers = {
    'Authorization': f'Bearer {COUNT_API_KEY}',
    'Content-Type': 'application/json',
}

response = requests.request(
    "GET",
    "https://api.eu.count.co/v1/connections/connection_key",
    headers=headers,
)

print(response.json()["result"]["agent_context"])

PATCH Connection context

import requests

COUNT_API_KEY = '...'

headers = {
    'Authorization': f'Bearer {COUNT_API_KEY}',
    'Content-Type': 'application/json',
}

json = {
    'agent_context': 'This connection hosts our production warehouse...'
}

response = requests.request(
    "PATCH",
    "https://api.eu.count.co/v1/connections/connection_key",
    headers=headers,
    json=json
)

#Why use the API to maintain context?

Treating agent context as a file instead of a UI field gets you everything tools like Git and GitHub already give you for code:

  • History and blame: every change to an agent's instructions is a commit, with an author and a reason, rather than a silent overwrite.
  • Review before it goes live: a change to the agent's instructions can go through a pull request, with a diff, before it affects anything.
  • A single source of truth: the repo is authoritative, so there's no drift between "what's live" and "what someone remembers editing in the UI."
  • Rollback: reverting a bad context change is a simple revert rather than a rebuild.
  • Use it elsewhere: managing context centrally allows you to use the same context across your agentic stack.

#An example approach

This is the pattern we put together in count-context-sync-toolkit, and it's deliberately simple:

  • Each destination (a workspace, project, or connection) gets one markdown file in the repo. The file's content is the context: what you write is what gets pushed.
  • A small script compares each file against what's currently live via the API.
    • It can be run in 'check' mode to identify differences between repo hosted context files and live Count context prior to merging.
    • On merge, it can be run to push any file that differs, overwriting live context in Count.
  • Two GitHub Actions wire this into normal Git workflow:
    • one comments a preview diff on pull requests that touch context files,
    • and one pushes automatically once those changes are merged to main.

Last updated: 11/09/26