OpenNekoRent the intelligence. Own the context.See a demoOpen source · Apache 2.0
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.
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
Brief the store lead + ops on the ETA
Slack · #ops
Approve once — or set a rule and OpenNeko handles it next time.
Using OpenNeko
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.
Top SKU will cross its reorder point tonight
Caught 2:14 AM · vendor 7 days out · PO #4471 drafted and waiting
A running read on the business. Anything that needs you sits up top.
In production
Real deployments, real systems, and real numbers across regulated defense technology and global commercial real estate.
A defense technology company
Snowflake · CRM
OpenNeko runs on their own network across Snowflake and CRM, spanning 80B+ records — scoring buying intent, flagging accounts before they churn, triaging the custom-quote queue, and keeping critical components in stock. It drafts the next move; the team approves.
A global commercial real estate firm
Azure Data Lake
Their analysts answer clients' questions across hundreds of millions of data points on property research, investment, and performance. Agents now do the legwork — an analyst asks in plain language, OpenNeko queries the full dataset and drafts the insight with its evidence, and the analyst signs off.
Under the hood
Each block does one job, and they work better together. Every action you approve teaches the agent how you want things done.
A watcher catches a problem while you can still do something about it. Describe it in plain language — “tell me if daily orders drop below 500” — and it checks your data on a schedule, then starts a workflow when the line is crossed. No SQL or cron.
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
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.
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.
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 …
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.
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.
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.
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.
A workflow is a saved process — the steps your team would take, written down once and run whenever they’re needed. Describe it to OpenNeko in plain language, and set it to run on a schedule, when a record changes, or when a watcher fires.
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.
A trigger fires
Observe: pull the relevant data
Understand: check memory and your rules
Decide: draft what to do
Act: on your approval
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.
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.
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.
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.
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.
Architecture
Ask in plain language. OpenNeko's agents break the question down and read your databases through GraphJin — compiled straight to SQL, computed where your data already lives.
OpenNeko runs as three tiers, split by trust. A small control plane — the worker — holds your secrets, your database access, and the model gateway. Everything that runs model-written or third-party code runs sandboxed beside it, reaching the control plane through one narrow broker.
Security and Governance
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.
The threat model
The agent reads data and documents you don't control and runs them through a model, so OpenNeko treats it as untrusted code. In most systems that agent holds the most access — the keys, the database, the network. OpenNeko flips that: the agent runs sandboxed, and the worker holds everything.
Say a malicious record fully hijacks the model, and the agent does whatever an attacker wants. Its blast radius is only what it was already given — which is almost nothing.
A fully compromised agent can say things and request approval-gated actions. Nothing more. That equivalence is the architecture working.
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.
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
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
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.
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.
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.
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
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.
Certified data engineer with years building data systems that handle real volume. The data layer is where OpenNeko earns its trustworthiness.
Deployed AI workflows that added or saved tens of millions to the bottom line. Built agentic systems before agents were a trend.
Security-audited Fortune 500 companies. Knows what breaks in regulated environments and what compliance actually requires.
Two ways to start
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.
