Skip to content

Conversation

@grypez
Copy link
Contributor

@grypez grypez commented Oct 8, 2025

This PR introduces a new @ocap/kernel-agents package that provides capability-enabled AI agents.

Changes

New package @ocap/kernel-agents

  • provides a makeAgent factory for producing capability-augmented AI agents from a LanguageModel and a CapabilityRecord

@ocap/kernel-language-model-service

  • Updated LanguageModel.sample to return { stream, abort }, which allows downstream consumers to stop the LLM from generating more tokens (useful when you know the generation is invalid midstream)
  • Updated ollama service implementations to support the new sample interface

Note to Reviewers

See README.md for local e2e test setup.


Note

Adds a new capability-driven agent package and changes LanguageModel.sample to return an abortable stream ({ stream, abort }).

  • New package: @ocap/kernel-agents
    • Agent factory makeAgent with default end capability and capability invocation flow.
    • Prompt/transcript system (messages, prompt, example transcripts/capabilities) and incremental JSON streaming parser.
    • Comprehensive unit + E2E tests (Ollama-based), README, build/test configs.
  • Language model service (@ocap/kernel-language-model-service)
    • BREAKING: LanguageModel.sample now returns { stream, abort } (abortable streaming).
    • Update Ollama base/nodejs implementations and tests to new interface; export root types entry.
  • Repo config
    • Add packages/kernel-agents to TS project refs and Vitest coverage thresholds; workspace wiring in lockfile.

Written by Cursor Bugbot for commit 84cbf32. This will update automatically on new commits. Configure here.

@socket-security
Copy link

socket-security bot commented Oct 8, 2025

No dependency changes detected. Learn more about Socket for GitHub.

👍 No dependency changes detected in pull request

@grypez grypez force-pushed the grypez/kernel-agent branch 4 times, most recently from 0f7fb26 to bbc62fa Compare October 9, 2025 13:11
@grypez grypez changed the title WIP: kernel agents Add @ocap/kernel-agents package Oct 9, 2025
@grypez grypez marked this pull request as ready for review October 9, 2025 16:30
@grypez grypez requested a review from a team as a code owner October 9, 2025 16:30
@grypez grypez mentioned this pull request Oct 9, 2025
4 tasks
Copy link
Member

@rekmarks rekmarks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's great to see your sojourn in agent-land come together in such a well-conceived package. See various comments in-line. We should be able to get this merged in no time!

/**
* Test constants for E2E tests
*/
export const DEFAULT_MODEL = 'llama3.1:latest';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Out of curiosity, how did we choose this and often do we expect to change it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fit for the test setup: available in ollama, relatively small
Fit for purpose: trained for tool use, trained to produce json outputs

In practice the prompts should be optimized to the models; the test suite is biased toward this choice of model.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the stuff in here be exported from the language service package? Or perhaps repo-tools?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe later. The suite.test.ts tests that the local ollama server is running and prepared correctly (i.e. the model is pulled), which is a sort of liveness assurance above and beyond what the language service package promises. Putting the constants in repo-tools graduates them to a scope that exceeds current need.

This suggestion does point to broader question of separating the code and the data for the agent framework; for example, prompts are.... probably code? But also model dependent. And models are.... probably data? But we are using them to determine flow control of our program.

I think leaving these under the kernel-agents/test/ directory is the tidiest choice for the moment.

return {
task: async (
query: string,
{ invocationBudget = 10 }: { invocationBudget?: number } = {},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's this for?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's the number of times the agent can invoke capabilities before the task throws. You can imagine that by the 10th call to a tool without completing the task, this particular approach is probably not going to succeed.

Copy link
Member

@rekmarks rekmarks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I meant to request changes in my previous review)

cursor[bot]

This comment was marked as outdated.

cursor[bot]

This comment was marked as outdated.

Copy link
Member

@rekmarks rekmarks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

Let's leave remaining comments unresolved. Some of it is documentation that should arguably be committed, but at least we can leave it easily accessible for Those Who Follow (i.e. ourselves, next week).

@grypez grypez enabled auto-merge (squash) October 15, 2025 11:07
@grypez grypez force-pushed the grypez/kernel-agent branch from 6437b85 to 84cbf32 Compare October 15, 2025 11:07
logger?.info('results:', results);
const didEnd = results.find((capability) => capability.name === 'end');
if (didEnd) {
logger?.info('exit invocation with result:', didEnd.result);
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: Task Logs Missing Specific Context

The results and exit invocation logs on lines 84 and 87 use the general logger instead of the task-specific taskLogger. This causes these important task-related messages to miss their task context, like the task ID.

Fix in Cursor Fix in Web

);
expect(result).toBeDefined();
expect(countSpy).toHaveBeenCalled();
expect(result).includes(word.length.toString());
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bug: Invalid Matcher Usage in Tests

The tests incorrectly use .includes() directly on the expect() object, which isn't a valid Vitest/Jest matcher. This means the assertions aren't checking what's intended.

Additional Locations (1)

Fix in Cursor Fix in Web

@grypez grypez merged commit 6b4498b into main Oct 15, 2025
23 checks passed
@grypez grypez deleted the grypez/kernel-agent branch October 15, 2025 11:16
grypez added a commit that referenced this pull request Oct 15, 2025
This PR contains two minor fixes for the recently added kernel agents
package (#668).
- Two test expectations at the end of agent end to ends tests were no
ops
- The agent's task method was logging to the base logger instead of the
taskLogger
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants