The vendor pushed delivery to 7 days. At the current pace, stock crosses the reorder point before midnight.
Sales held at about 172 a day this week. Your reorder rule for this SKU triggers at the cover line.
Open source · Elastic License 2.0
AI Agents built to run
your factory.
OpenNeko's AI agents connect to your databases and APIs and watch for problems while you can still act on them. When an agent finds one, it drafts a response and waits for your approval.
OpenNeko2:14 AM · watching
Top-selling SKU will cross its reorder point tonight.
Primary vendor is 7 days out · 385 units left · selling ~172/day
Drafted 2 Actions — Awaiting Approval
Rush replenishment to the backup vendor
PO #4471 · arrives before stock-out
ApproveReject
Brief the store lead + ops on the ETA
Slack · #ops
ApproveReject
Approve once — or set a rule and OpenNeko handles it next time.
01ObserveWatches your systems and data around the clock.
02UnderstandWorks out what changed, using your data and your rules.
03DecideDrafts the specific action to take, with its reasoning.
04ActRuns only after you approve, or under a rule you set.
Using OpenNeko
How you work with the agent.
OpenNeko is an AI agent that watches your databases and APIs. When it spots something, it proposes what to do, then waits for your approval before acting. The agents work in a loop: observe, understand, decide, act. We call it OUDA.
Dashboard
The agent keeps a running briefing on the business. It's a plain read on how things stand right now, and anything that needs you sits up top.
Ask
Ask a question about any number in plain language, and the agent answers straight from your database.
Rules
You decide how far the agent can go on its own. Some actions it just handles; the rest wait for your approval. To add a rule, tell the agent what you want and it does the rest.
Actions
When something needs your sign-off, it lands here with the agent's reasoning attached. Approve it or send it back. Either way, it's on the record.
OBSERVEWhat is happening
An agent watches your databases and APIs for change. Watchers run on a schedule, and subscriptions react the moment a record changes.
Most of the time nothing needs you. When something does cross a threshold, the agent records it and the loop picks it up.
Orders on track
Days-of-cover dropping
Vendor past SLA
UNDERSTANDWhat it means here
A change on its own means little. The agent interprets it using what it has learned about your business and the current numbers from your database.
You can also ask in plain language, and the agent answers from the same data, with the evidence.
Why is days-of-cover dropping on the top SKU?
DECIDEWhat should happen next
This is where the agent decides what to do. It drafts the actual action to take, using a skill that captures how your team handles the situation and a plugin to carry it out.
Nothing happens yet. The draft waits for you, with the reasoning attached.
Rush replenishment to the backup vendor
Approve or reject, or auto-send under your reorder ruleBrief the store lead on the ETA
Approve or reject, posts to SlackACTFollow through, on your call
Approve it, and the agent carries it out through the right plugin. For actions you have pre-approved, it acts on its own within the rules you set. Only external, irreversible actions need approval, and every one is logged.
The agent also remembers your decision, so its next draft for a similar case starts closer to being right.
02:14Watcher fired: top SKU crossed reorder
07:30You approved, PO sent via the vendor plugin
07:30Memory: confirmed reorder rule for SKU-1182
In production
Already in use across real operations.
These are live deployments, kept anonymous at the customers' request. They range from a solo operator on a single database to teams across a large enterprise.
Retail · InventoryTheir AWS
A 40-store regional grocery chain — Postgres + Shopify
Stockouts on top products were only caught after the shelf was empty.
A watcher tracks stock cover for each product. When it falls below the reorder point, OpenNeko drafts the purchase order and sends it for approval.
→ Your metric here, e.g. stockouts down 60% in the first month
Logistics · SLAOn-prem
A regional 3PL moving ~2,000 shipments a day — custom TMS
Late shipments were only noticed when the customer called to complain.
A watcher flags any shipment running past its SLA. OpenNeko proposes a re-route for the team to approve.
→ Problems are caught while there is still time to fix them.
Representative scenarioFinance · CollectionsTheir GCP
A B2B subscription business — Postgres + Stripe
Failed payments went unnoticed until the monthly close.
A watcher monitors failed charges. OpenNeko drafts the retry and the customer email, and sends the pre-approved ones automatically.
→ Recoverable revenue is handled the day a payment fails.
Representative scenarioUnder the hood
Five building blocks that improve with use.
Each block does one job, and they work better together. Every action you approve teaches the agent how you want things done.
01 · Watchers
A watcher checks your data on a schedule. When a value crosses the line you set, it starts a workflow. That is how OpenNeko catches a problem while you can still do something about it.
Catch the change early
A watcher is a standing question about your data. For example: are daily orders below 500? It runs on your schedule and stays quiet until the answer changes.
When the condition is met, the watcher starts its workflow, and an agent works out what to do about it. The finding shows up on your briefing.
Orders on track
Days-of-cover dropping
Vendor past SLA
Set it in plain language
Say “tell me if daily orders drop below 500,” and OpenNeko turns it into a scheduled query with a threshold. You do not write SQL or cron.
Set how often it checks, and a quiet period so it tells you once, not every five minutes.
Days-of-cover drops below the reorder point
Daily orders fall under 500
A vendor misses its delivery SLA
Failed-payment rate rises week over week
For builders
A watcher runs a GraphJin query on its schedule (minimum 60s, default 300s) and reads a value at a JSON path. It compares that value against a threshold using an operator: gt, gte, lt, lte, eq, ne, or changed. When the condition holds and the debounce window (default 1h) has passed, it queues a workflow run.
02 · Skills
A skill teaches an agent how to handle a task the way your business does. Each one is a SKILL.md file: Markdown with a short YAML header, the same open format Claude Code uses.
Your know-how, written down once
When an agent faces a task it has a skill for, such as building a DCF model, it follows that skill. The skill describes how your team does the work, in plain Markdown the agent can read.
Write a skill once and every agent applies it the same way. A skill can include helper scripts, but many are just text.
---
name: dcf-model
description: Build a discounted-cash-flow valuation
license: Apache-2.0
allowed-tools: [bash, xlsx-author]
---
# DCF model
Project free cash flow, discount at WACC …
Portable and yours to keep
Skills are plain files, so you can review them in a pull request and keep them in version control. Your operating knowledge stays with you, not locked inside a vendor's product.
You can install a community skill from a git URL. OpenNeko also ships built-in skills, including financial models and document authors.
3-statement-model · dcf-model · lbo-model
comps-analysis · merger-model
xlsx-author · pptx-author · docx · pdf
internal-comms · skill-creator
For builders
A skill is a SKILL.md file following the agentskills.io spec. The YAML header sets name, description, version, allowed-tools, and optional prerequisites. The Markdown body holds the instructions, with optional helper scripts. Install community skills with openneko install <git-url>; they validate against the spec and load on the next agent run.
03 · Plugins
A plugin is how an agent takes action in another system, such as sending a Slack message or updating a Shopify order. Each plugin runs in a sandbox and can only reach the systems it declares.
Take action in other systems
Answering a question is one thing; doing something about it is the point. A plugin gives an agent a set of actions it can take in another system. Once you approve a draft, the plugin carries it out.
OpenNeko ships the plugins most teams need, and more are added over time.
SlackMessage, DM, react, and channel
ShopifyRead and update orders
Google WorkspaceGmail, Sheets, Calendar, Drive
TelegramInbound and outbound channel
Web searchSearch and fetch
Sandboxed and scoped
Every plugin runs in its own OpenShell sandbox. It can reach only the hosts its manifest lists, and a plugin that lists none can reach nothing. Its secrets stay in a file the agent never sees.
A plugin can do its job and nothing else. That is what lets a security team approve it.
network: [ slack.com ]
actions: [ send_slack_message ]
secrets: from the host, never in the box
For builders
You define a plugin with definePlugin(). Its manifest declares the capabilities it offers (action, auth, connect, or channel), the hosts it may reach, and the secret keys it needs. Each plugin runs in its own OpenShell sandbox with a per-host, per-binary egress allowlist. Install from the first-party marketplace or a git URL; the sandbox and manifest rules apply either way.
04 · Workflows
A workflow is a saved process: the steps your team would take, written down once and run whenever they are needed. You create one by describing it to OpenNeko in plain language.
Describe it, and OpenNeko writes it
Tell OpenNeko what you want done, and it writes the workflow for you: a goal, the steps, and when to run. Each run produces an output that other workflows can watch.
Workflows can feed each other. When one produces an output, any workflow that subscribes to it reacts. No workflow decides whether its own output matters; the ones watching it do. This lets the system handle cases no one planned for.
1
A trigger fires
2
Observe: pull the relevant data
3
Understand: check memory and your rules
4
Decide: draft what to do
5
Act: on your approval
How a workflow starts
A workflow can run on a schedule, when a record in your database changes, or when a watcher's condition is met. You set this when you save it.
Steps that change something outside OpenNeko pause for your approval. For actions you have pre-approved, the workflow runs them based on the rules you set.
Schedule — “every weekday at 8am, brief me”
Data change — “when a customer becomes at-risk”
Watcher — “when daily orders drop below 500”
Manual — start it yourself from the Run page
For builders
A workflow is a workflow_definition. A builder agent saves one by emitting a structured block with its name, goal, steps, and triggers. A trigger is a cron schedule, a source_change on a row (stored as a subscription), or a watcher condition. Each run emits workflow_outputs that other workflows can subscribe to.
05 · Memory
Memory is how OpenNeko gets better at your business. The rules you confirm and the preferences an agent learns are stored in your own database and used on later runs.
Confirm it once, and it stays
When an agent learns something, such as how you define an “active customer,” it saves it to memory. On later runs, the agent finds the relevant memories by meaning and uses them.
A rule you confirm once applies on every future run. The more you correct the agent, the more accurate it gets, always within the rules you set.
TueWatcher fired: top SKU below reorder
TueYou approved, and saved a reorder rule for SKU-1182
FriSame SKU dips, the rule is recalled, the draft is already right
Typed, pinned, exportable
Memory is plain Postgres, so it is yours to export and back up, and it never trains anyone else's model. Each item has a type, and you can pin the ones that should always apply.
Memory holds what an agent has learned about how you work. Findings, action policies, and decision logs are kept in their own tables.
business_rule — what you've approved it to do
preference — how you like things done
metric_definition — what a number actually means
company_context — durable facts about the business
correction — where it was wrong before
For builders
Memory is one Postgres table, work_memory, with a pgvector embedding column. An agent writes typed items: preference, business_rule, metric_definition, correction, company_context, and thread_note. On later runs they are loaded by pin and by semantic vector search on the current task, then added to the prompt. The text is the source of truth, and embeddings can be re-derived.
For builders
How it's all wired.
OpenNeko is built around one rule. The control plane is the only place that holds your secrets, your database access, and the model gateway. Anything that runs model-written or third-party code runs in a sandbox that holds none of those.
01The trust gradient
There are three tiers. The worker is the control plane, and it is the only part that holds your secrets, your database access, and the model gateway. Next to it are two sandboxed tiers: the agent loop, and one sandbox for each installed plugin.
The agent and the plugins run model-written and third-party code, so they get no keys and no database. They reach the control plane only through a narrow broker, using a token scoped to one run.
worker — secrets, database access, model gateway, policy
agent sandbox — the LLM loop, no key, no database
plugin sandboxes — one per plugin, allow-listed
Postgres, GraphJin, pg-boss
02Two agent backends
The agent loop runs one of two backends: NousResearch's hermes-agent, which is the default, or the Claude Agent SDK. Both reach the control plane through the same broker, and you choose which to use per organization.
Use any model provider, or a local model through Ollama. The key stays on the gateway side. The backend inside the sandbox only ever holds a placeholder.
backend: hermes # or claude-agent
model: your provider, gateway-side
key in the box: openshell:resolve:env:…
03Reads and writes are separate
GraphJin, a GraphQL-to-SQL compiler running as a sidecar, handles reads. An agent queries your data through it, read-only and guarded, and the same engine powers the subscriptions that drive the loop.
Writes go through a typed Drizzle layer into Postgres. So GraphJin reads what Drizzle writes. pg-boss, on the same Postgres, runs the schedules.
GraphJin — GraphQL to SQL, reads and subscriptions
Drizzle — typed writes to Postgres
pg-boss — cron and subscription firings
all on your own Postgres
You ask
“Why is the top product running low?”
AI Agents
OpenNeko Agents
Decompose the question and plan the data fetch.
Query Engine
GraphJin
Compiles to optimized SQL across your databases.
PostgreSQL
MSSQL
Snowflake
MongoDB
Security and Governance
Your data and your model stay on your infrastructure.
The agent and its plugins run in a sandbox with no access to your keys or your database. Your model's API key never enters it. Run a local model and no data leaves your network.
Your cloud
Deploy into the AWS, GCP, or Azure account your team already uses. Your data stays inside your own perimeter.
On-prem
Self-host on your own server. It needs only Docker, with no virtualization.
Your model
Use any LLM provider, or a local model through Ollama. With a local model, no data leaves your network.
01Everything runs in a sandbox with no keys and no database
The agent loop and every plugin run inside NVIDIA OpenShell sandboxes. These are plain containers, so the host needs only Docker. Neither sandbox holds a database credential or a secrets file.
Outbound network access is denied by default and allowed only to specific hosts, through a proxy. Landlock and seccomp limit what the code can touch on disk and which system calls it can make.
Outbound network denied by default, allowlist only
Landlock filesystem confinement
seccomp syscall filtering
No database credential, no secrets file in the box
02Your model key never enters the box
The sandbox holds only a placeholder. The real model key stays on the gateway, and the proxy adds it to the request on the way out. The agent never sees the key.
The agent reaches the control plane only through a narrow broker, using a token scoped to one run. Before anything an agent writes is stored, a scrubber on the host removes any secret that appears in it.
API_KEY = openshell:resolve:env:…
real key added to the request, gateway-side
never written to the box, never logged
03Plugins reach only what they declare
Each plugin's manifest lists the hosts it may reach and the secrets it needs. OpenShell allows only those hosts, per binary. A plugin that lists no hosts can reach nothing.
Secrets live in a host file the agent cannot read, encrypted at rest. You can manage them across a deployment with an optional Infisical backend.
network: [ slack.com ]
actions: [ send_slack_message ]
secrets: from the host, never in the box
04Nothing irreversible runs without a decision
Anything an agent does outside OpenNeko runs through a policy. By default the action is drafted and queued for a person to approve. Reads, briefings, and memory updates are not gated; only external, irreversible actions are.
Each kind of action has a mode that you set. It can require approval every time, run on its own under a risk threshold, prepare a draft only, observe only, or never run.
approval_required — a person approves it
auto_approve — runs within a risk threshold
draft_only — prepared, never sent
observe_only — intent recorded, nothing runs
never — rejected and logged
05Every decision is on the record
OpenNeko records the full chain behind every action: the finding that triggered it, the draft, who approved it, and the result. These records are kept.
Each one carries two identities, the person who acted and the agent backend that proposed it. Every privileged call an agent makes to the control plane is recorded the same way.
FindingTop SKU crossed its reorder point
ProposedRush PO to the backup vendor
ApprovedYou, as admin, via hermes
ExecutedPO sent, ref #4471
06Roles and data access
Access is role-based. An admin manages the organization, a member works within their own layer and can approve member-level actions, and automated runs act as a read-only service.
In agentic mode, the database engine itself blocks writes and arbitrary queries from an agent, using a short-lived identity minted for each run. The agent has no route to OpenNeko's own control-plane database.
admin — manages the organization
member — own layer, approves member actions
service — automated runs, read-only
agent — blocked from writes, per-run identity
For builders
The only outbound traffic is to your chosen model endpoint and the hosts your plugins declare. Everything else is denied. A hardened profile warns you when the model host is a public-cloud API. A packaged air-gapped mode is on the roadmap; using a local model works today.
Who built it
20 years shipping the three things this product has to get right.
Amit Deshmukh
AI Engineer · Creator of AxCrew.dev & OpenNeko · Founder @ Buddhic.ai
linkedin.com/in/amitdeshmukh ↗
Amit has spent the last 20 years working hands-on across all three.
Data engineering
Certified data engineer with years building data systems that handle real volume. The data layer is where OpenNeko earns its trustworthiness.
AI engineering
Deployed AI workflows that added or saved tens of millions to the bottom line. Built agentic systems before agents were a trend.
Enterprise security
Security-audited Fortune 500 companies. Knows what breaks in regulated environments and what compliance actually requires.
Two ways to start
Install it now, or see the demo first.
Self-host it in a few minutes on your own infrastructure. Or send us the problem you most want solved, and we'll show you how OpenNeko would handle it.