Redux gave components shared state between renders. gcontext gives agents shared state between sessions.
Find an agent or build your own. Running in minutes.
Explore browser actions with AI, then crystallize them into reusable Python scripts. Recipes self-heal: when a script fails, the agent falls back to live exploration and updates the recipe.
A release agent that collects changes, drafts a changelog, bumps the version, publishes, and optionally announces. Each release is a searchable run; the agent learns your changelog style and known blockers over time.
Research keywords, discover content opportunities, and build a prioritized list of content ideas. Each run explores a seed topic and produces actionable suggestions, not finished articles.
A support agent that resolves tickets, logs every action, and builds playbooks from experience. Each resolved ticket becomes a searchable record; repeated patterns become reusable playbooks the agent consults on future tickets.
Agents you install into an instance run inside it together. They share one memory and one set of connections, so you set up a service once and every agent can use it.
Install a support agent and an ops agent: the ops agent can read what the support agent learned. Each new agent starts with everything the instance already knows.
gcontext splits everything into two main categories: connections and modules. Connections are the agent's access to external services, while modules are the knowledge and playbooks the agent accumulates over time.
Who the agent is and what it does. Every connected runtime receives this text at the start of every session.
One folder per service. A YAML file declares the secret names and dependencies. A markdown file explains the API in practice. The agent reads the docs and writes the script.
Knowledge the agent accumulates. One topic per folder. Playbooks and logs fill in over time.
Secret values live here, gitignored. The agent sees the names but never the values. Values are injected at run time and scrubbed from every output.
Three commands. The server starts and prints an MCP URL.
Once per client, works from any directory. Any MCP client works.
With the MCP connected, run the built-in setup prompt. Describe what you need in plain words. The agent proposes connections and modules, builds them, and verifies each one.
Replace my-agentwith your agent's MCP server name.
A connection gives your agent access to one external service. Each connection is a folder with a YAML manifest for secret names, a markdown file with practical API notes, and a scripts folder for proven procedures.
Learn more →An agent is a module you install into your gcontext instance. It gives the instance a repeatable process: steps to follow, playbooks to consult, and logs to learn from. Each run leaves a trace, and the agent gets better over time.
Learn more →