Skip to content
UseAgent

Institutional Knowledge

Your team
gets smarter.

Turn useful work into shared knowledge your team reviews before publishing, with optional memory you can choose to enable.

Learning review
  • How to fix widget timing bugtrace of 4 failed attempts → fixproposed
  • Deployment checklist for servicesordered steps from successful deployproposed
  • Auth troubleshooting flowchartpublished
Illustrative example

Reviewed team memory

Facts your team learns and remembers. Salience-gated. Human-reviewed. Optional.

Salience-gated capture

Not every run gets remembered. High-value runs (you define the threshold) propose knowledge entries with ordered procedure traces and redacted evidence. Nothing auto-publishes.

Learning lane review

Proposed entries sit in /learnings for human review. Accept them to publish. Reject them to discard. Accepted drafts that cluster together become skill revision proposals.

Org + team scope

Memory is optional. Enabled via external memory-core container. User or team boundary: you choose. Disabled by default to keep every run fast.

SEE IT WORK

One agent. Real tasks.

UseAgentExample workflow

Our widget service returns 500 on DELETE /widgets/:id when the widget has 3 or more linked components. Fix it.

  • Clone and search

    Cloned repo, found DELETE handler in handlers/widgets.ts. Searched error logs. Every 500 has 'permission check failed' after component count check.

  • Reproduce locally

    Set up test DB with 3 linked components, sent DELETE request, confirmed 500. Traced the stack: permission middleware runs after cascade check, causing the 500.

  • Fix the order

    Moved permission check before cascade. Added test case: DELETE with 3+ components now returns 204. Old test suite still green.

  • Open PR

    Created PR #487: 'Fix widget delete with linked components'. Added test case to prevent regression.

Questions, answered.

Is memory mandatory?

No. Memory is optional. Disabled by default. You enable it by configuring MEMORY_API_URL and the memory-core container.

Can agents write memory directly?

No. Memory is written only via the learning lane after the run completes, and only for high-value runs. Agents can read (recall) but not write.

Can one team member's memory be seen by another?

Depends on your scope. Memory can be user-scoped or team-scoped. Team scope means all team members see and add to the same memory. You choose when you enable it.

Start with one task.
See what you can hand off.

Explore a completed run, or join the early-access list to hear about getting your team started.