Build proactive AI agents on a graph
that builds itself
Connect your company's data in real time, plug in your model, and let your agents act the moment something changes, as a bot, an API, or another agent.
Paste it into claude code, cursor, or opencode, and it scaffolds the project for you.
Or start it yourself:
Raw events in. Typed memory out. Agents act.
Connectors stream events into memory. Watchers derive typed entities. Agents read it, talk to users, and act.
One typed file wires it together.
Pick a piece to see the code for this use case. Click again to hide.
import {
connectorFromFile,
defineAgent,
defineConfig,
defineEntityType,
defineRelationshipType,
defineWatcher,
reactionFromFile,
secret,
} from "@lobu/cli/config";
import type ExaNewsFeedConnector from "./exa-news-feed.connector.ts";
import type founderActivityTrackerReaction from "./founder-activity-tracker.reaction.ts";
const vcTracking = defineAgent({
id: "vc-tracking",
name: "vc-tracking",
description:
"Track companies, founders, and investment opportunities for venture firms",
dir: ".",
providers: [
{
id: "anthropic",
model: "claude/sonnet-4-5",
key: secret("ANTHROPIC_API_KEY"),
},
],
network: {
allowed: [
"github.com",
".github.com",
".githubusercontent.com",
"registry.npmjs.org",
".npmjs.org",
],
},
});
// entity types and relationships defined here…
const founderActivityTracker = defineWatcher({
agent: vcTracking,
slug: "founder-activity-tracker",
name: "Founder Activity Tracker",
schedule: "0 10 * * *",
notification: { priority: "normal" },
tags: ["vc", "founders", "daily"],
minCooldownSeconds: 600,
reaction: reactionFromFile<typeof founderActivityTrackerReaction>(
"./founder-activity-tracker.reaction.ts"
),
prompt:
"You are a venture capital analyst tracking the public activity of startup founders in your portfolio.\n\n## Founders\n{{#each entities}}\n- {{name}} ({{entity_type}}, ID: {{id}})\n{{/each}}\n\n## Recent Founder Activity\n{{#if sources.founder_posts}}\n{{sources.founder_posts}}\n{{/if}}\n\n---\n\nProduce a structured founder activity report:\n1. **Executive Summary**: 2-3 sentence overview of founder activity and signals.\n2. **Per-Founder Analysis**: For each active founder, summarize their messaging themes, engagement level, and signals about company direction.\n3. **Cross-Portfolio Patterns**: Themes multiple founders discuss.\n4. **Notable Signals**: Flag potential announcements, strategic shifts, or concerns.\n\nBe specific and cite actual tweets/posts as evidence.\n",
sources: {
founder_posts:
"SELECT id, title, payload_text, author_name, source_url, occurred_at, score, origin_type, connector_key FROM events WHERE connector_key IN ('x') AND origin_type IN ('tweet', 'reply') ORDER BY occurred_at DESC LIMIT 300\n",
},
reactionsGuidance:
"When a founder signals hiring activity, fundraising, or pivots, flag for the investment team.\nTrack founders going quiet as a potential concern.\nAlert on any public statements about competitors or market conditions.\n",
extractionSchema: {
type: "object",
required: ["summary", "founders", "notable_signals"],
properties: {
summary: { type: "string" },
founders: {
type: "array",
items: {
type: "object",
required: ["name", "company", "activity_level", "themes"],
properties: {
name: { type: "string" },
company: { type: "string" },
activity_level: {
type: "string",
enum: ["high", "medium", "low", "inactive"],
},
themes: { type: "array", items: { type: "string" } },
sentiment: {
type: "string",
enum: ["bullish", "neutral", "cautious", "concerned"],
},
signals: { type: "array", items: { type: "string" } },
notable_posts: { type: "array", items: { type: "string" } },
},
},
},
cross_patterns: {
type: "array",
items: {
type: "object",
properties: {
theme: { type: "string" },
founders_involved: { type: "array", items: { type: "string" } },
},
},
},
notable_signals: {
type: "array",
items: {
type: "object",
required: ["signal", "founder", "impact"],
properties: {
signal: { type: "string" },
founder: { type: "string" },
impact: { type: "string", enum: ["high", "medium", "low"] },
},
},
},
},
},
});
export default defineConfig({
connectors: [
connectorFromFile<typeof ExaNewsFeedConnector>(
"./exa-news-feed.connector.ts"
),
],
org: "market",
orgName: "Market",
orgDescription:
"Track companies, founders, and investment opportunities for venture firms",
agents: [vcTracking],
entities: [
company,
founder,
fundRound,
investor,
jobPosting,
product,
sector,
],
relationships: [
educatedAt,
foundedBy,
headquarteredIn,
inIndustry,
inSector,
investedIn,
mentions,
operatesIn,
previouslyAt,
primaryRelationshipOwner,
roundLedBy,
roundOf,
sourcedBy,
usesTechnology,
worksAt,
],
watchers: [founderActivityTracker, opportunityMatcher],
});Pick a use case to see it end to end.
Each page walks through the connectors, memory shape, and watchers for one team, and ships as a working example you can lobu apply.
Local, your cloud, or Lobu Cloud.
Same lobu.config.ts + *.connector.ts + agents/. One command to boot embedded; Docker + Helm for self-hosting; Lobu Cloud when you don't want to run it yourself.
Embedded, single process.
Gateway, workers, memory, embeddings, all in one Node process. Postgres is the only external.
$ lobu run → gateway :8787 → worker pid=<n> → memory N entities → watchers N armed
Docker. Helm. Your cloud.
Helm chart and Dockerfiles in the repo (charts/lobu/, docker/app/). Run on GCP, AWS, Fly, Render, or bare metal.
# Kubernetes $ helm install lobu ./charts/lobu # Docker $ docker build -f docker/app/Dockerfile .
Managed runtime.
Same code, run by Lobu. Per-user isolation, secret proxy, automatic upgrades.
$ lobu apply → org <your-org> → region <your-region> → agents N deployed → gateway <your-org>.lobu.run
Build your first
multi-user agent.
Latest blog posts
Shopify's Aquifer, in the Open
Shopify bet that an agent's corpus is the compounding asset. We made the same bet, with two differences: we keep the signal instead of the chat, and we built it for many companies instead of one.
Filesystem vs Database for Agent Memory
Agents need a workspace to think in and a warehouse to remember in. The filesystem is for ephemeral work. The memory layer is for durable organizational knowledge.
MCP Is Overengineered, Skills Are Too Primitive
MCP HTTP is great for external services. MCP stdio is redundant. And most skill systems are just prompt text with no reproducibility. Here's what we built instead.