Home › Agents

One memory. One rulebook. Your own agents.

Your workflow.
Your supporting cast.

Bring reviewer, helper, and follower agents into the coding workflow you already use. Choose the models behind the roles. Give each a job worth doing.

Marketing concept. Role examples explain the intended experience, not a live demonstration or a release support promise. Spontaneous Memory below is a proposed capability.

Your main agent doesn't have to do every job.

A second perspective. A focused pair of hands. Someone keeping an eye on the bigger picture. Different roles, working around the same task.

01 · REVIEWER

Another set of eyes.

Bring in an agent to examine changes, question assumptions, and surface issues before you move on.

Example brief: “Review this change for failure paths and explain what needs attention.”

02 · HELPER

A job of its own.

Give a helper a bounded task alongside the main work: investigate a question, check an assumption, or prepare a focused result.

Example brief: “Check the relevant documentation and report the constraints.”

03 · FOLLOWER

The wider view.

Have a follower track work as it develops and contribute observations without taking over the main task.

Example brief: “Watch for decisions that conflict with the project's earlier direction.”

Your logic, at the agent's hooks.

At the heart is the open-source framework we're preparing for release: a place to connect your own code to supported events in the AI workflow.

Define the job. Choose the model.

Use different models for different roles across supported providers. A reviewer needn't use the same model as the agent doing the work.

Give each role instructions, relevant context, and a clear scope. The framework is the foundation; the frontend is where those roles and their work become visible.

The framework idea

When this happens…
A supported event makes relevant work available.

…run your logic…
A check, a reviewer, or another focused contribution.

…within its authority.
Advice, observation, and permission to act are different things.

Provider choice depends on available integrations and credentials. Triggers, context access, execution and delivery vary by role and runtime; this concept does not promise arbitrary-provider compatibility or identical controls everywhere.

The framework and your configuration

The machinery is shared. The workflow is yours.

Crossing Guard provides the mechanisms. Your configuration describes how you want to use them. You don't have to adopt our development process to use the framework.

Framework

The connections to supported agent hooks, the machinery for running checks and evaluating rules, and the records of what happened. It defines the available capabilities and their boundaries.

Configuration

Your chosen models, agent instructions, selected rules, and workflow criteria. What should a reviewer look for? Which facts matter to your project? Those choices belong to you, not hidden inside the framework.

Custom code

When existing mechanisms aren't enough, extend the framework at supported integration points. Add a check or integration, then configure how your workflow uses it.

One reviewer, different projects · illustrative example

Shared mechanism: run a reviewer and record its findings.

Your configuration: choose its model and instructions—review database changes for one project, accessibility for another.

An extension when needed: connect a project-specific checker through a supported integration point.

The frontend makes those choices visible.

The interface brings configuration and results together: what is selected, which agent contributed, and what it reported. Available controls depend on the implemented role and integration; configuration is not a promise that every option has a visual editor.

A supplied configuration pack is a starting point, not a mandatory workflow. Configuration cannot create a missing hook, enable unsupported live interruption, or grant an agent authority by itself. Spontaneous Memory's proposed delivery choices remain subject to those same boundaries.

Spontaneous Memory · proposed concept

The “aha” you didn't know to ask for.

Your main agent follows the task. A memory follower looks beyond that immediate context for a past decision, forgotten constraint, or relevant lesson that could change the work.

It isn't only remembering what you asked it to remember. It's making a useful connection to knowledge outside the main line of context—and bringing it back when it matters.

“Before you continue: we tried this approach before. Here's why we changed it.”

Illustrative message, not an actual retrieved memory or product transcript.

At a workflow event

Surface an insight at a supported checkpoint, when the working agent has an opportunity to use it.

During the work

For an important insight, interrupt the working agent where live delivery is supported and explicitly authorized.

Will a memory always interrupt my agent?

No. Event-triggered delivery, queued messages, and live interruption are different capabilities. An event or queued delivery must not be presented as an immediate interruption. Spontaneous Memory and its delivery behavior need implementation and runtime-specific verification before a release claim.

Does an “aha” give the follower permission to act?

No. A relevant memory is context, not an instruction with higher authority. The follower's contribution remains separate from permission to approve, change files, or control another agent.

Same workflow. More perspective.

Shared memory, shared rules, and your own supporting agents. The crossing guard stays at the intersection; you decide who joins the work.

Back to Crossing Guard →