NeuroBots — Put bots to work. Keep your hands on the keys.

Why bots, not another chat window

An assistant answers questions. An operator finishes work.

Chat is good at the first ten minutes of a job. The operational grind — the recurring, unglamorous work that quietly eats your week — needs something that survives the restart, remembers last Tuesday, and can prove what it actually did.

The work dies at the restart

A browser tab closes, a service reboots, a session times out — and a half-finished three-day task is simply gone, along with any idea of how far it got.

Work is queued in a database, not held in a page. A crash mid-task is redelivered on boot.

Every session starts from zero

You re-explain the same context every morning: which server, which client, what you decided last month and why you're not doing it the obvious way.

Each bot keeps durable, scoped memory and brings back only what's relevant to this turn.

It says it did the work

The worst failure isn't an error — it's a confident report about a file that was never written and a window that closed an hour ago. Nobody catches it until it matters.

Bots get real tools and a way to check ground truth, so claims are producible on request.

Meet the crew

One family, many jobs

You can tell a NeuroBot at a glance. What changes is the color, the face, the job, and the tools you let it hold. These six are where most teams start.

Night WatchInfrastructure

Verifies the backups actually restore, watches disks and certificate expiry, and wakes you only when something is genuinely wrong — not every night to say it's fine.

run_command · create_routine · notify_user

Firewall AuditorNetwork

Reads your house playbook before it writes a line, proposes changes with the exact commands, and arms the revert before touching anything on the edge.

asa_show · asa_configure · asa_save · asa_playbook

Inbox TriageMail

Sorts the morning inbox against your rules, drafts the replies that are always the same, and escalates the two messages that genuinely need a person.

search_gmail · read_gmail · send_gmail

Invoice RunnerBack office

Logs into the billing portal, pulls what's new, reconciles it against the ledger and flags every mismatch with the evidence attached — never the figure on its own.

login_to · read_website · write_file · send_to_agent

Portal WatcherSuppliers

Opens supplier portals in a real browser on its own screen — the ones with no API — compares this week's prices and terms to last week's, and reports the deltas.

open_website · read_website · remember · notify_user

Shift ReporterHand-over

Writes the morning note: what changed overnight, what the other bots did about it, and the short list of things still waiting on you.

search_history · search_memory · list_agents · notify_user

None of these are presets you're stuck with — they're the same bot with a different brief and a different set of tools switched on. Name yours whatever you like, and give it whatever face suits the job.

Anatomy of a bot

Four things each bot owns, and shares with nobody

A NeuroBot isn't a prompt with a nickname. It's a profile, a private record, its own memory and its own folder on disk — isolation enforced by the filesystem, not by a condition someone eventually forgets to write.

Give it a name, a job, and let it keep its own notes

Spin up a bot in a few seconds: a name, a role, a model. From then on it builds its own history — what it was asked, what it ran, what came back, what it decided — and that history is its alone. One bot can never read another's transcript.

Profile — name, role, avatar and the model it thinks with.
Transcript — append-only, in the bot's own database. Survives every restart, and is never visible to its peers.
Memory — facts in tiers and scopes, retrieved on a budget so remembered trivia never crowds out the actual task.
Workspace — a real directory of its own. No shared folder quietly overwritten by four bots at once.

agents/invoice-runner/

profileInvoice Runner · accounts payable · tools: files, mail, shell

store.db — transcript8,412 entries · append-only · private to this bot

store.db — memoryprofile facts always on · log facts ranked · notes on demand

workspace/reconciliation.csv · vendor-notes.md · 11 files

Memory budget 1,100 / 1,500 chars recalled this turn

Real reach

What a bot can actually touch

Capability, not instruction, is what stops a bot from role-playing the work. These are the actual tools a NeuroBot calls — each one audited, each one governed by a permission class you control.

Shell

Run real commands with a timeout and captured output. The workhorse behind every check, every script, every fix.

run_command

Files

Read, write, edit and list inside its own workspace. Paths from a model are treated as untrusted input and confined before anything touches disk.

list_files · read_file · write_file · edit_file · delete_file

Its own screen

Each bot gets a desktop window on the sandbox machine. You can watch it live and take over — and the bot can check what's really on screen before it claims anything.

open_screen · look_at_screen · close_screen

The web

Open a site in a real browser on its screen and read what the page shows — portals and dashboards included, not just tidy APIs.

open_website · read_website

Mail

Search and read the inbox, and send when you've allowed it. Triage, chase, acknowledge, escalate — the work that arrives as email.

search_gmail · read_gmail · send_gmail

Logins, without the secret

A bot asks to log in by name. The host holds the credential in an encrypted vault and performs the login — the bot never sees the password, not even in its own transcript.

list_logins · login_to

Network devices

Inspect and change a Cisco ASA firewall over SSH, with a playbook of house rules the bot must read before it writes, and an automatic revert if a change locks you out.

asa_show · asa_configure · asa_save · asa_rollback · asa_playbook · asa_status

Memory & history

Record facts worth keeping, search them later, and go back through its own transcript for what was said three weeks ago.

remember · search_memory · search_history

Every one of these calls passes through the host's own authorization and audit path before it runs — so an invoice bot reaching for the firewall is a refusal with a record, not a surprise. Per-bot tool switchboards are in build; see the status table.

Durability

Your turn always wins. Nothing else is allowed to stall you.

Background work runs in its own lane. The moment you type, the bot drops what it was doing and attends to you — and picks the background job back up afterwards.

Two lanes, and you own the fast one

Bots talk to each other, wake on a schedule and chew through long jobs. None of that is allowed to make you wait behind a queue. A request from you pre-empts the run in flight, and the interrupted work is genuinely stopped — not left finishing invisibly in the dark.

Protected user lane — peers can never crowd out the person.
Real interruption — pressing stop aborts the actual run, in any lane.
Boot recovery — a task that died mid-flight is redelivered when the host comes back, exactly once.
Priority, with limits — a bot can flag something urgent, but it cannot spam urgency to jump the queue forever.

scheduler · 4 bots · 2 lanes

user You → Night Watch running now · everything else waits

agent Invoice Runner · 60-invoice batch interrupted at 14 · resumes after your turn paused

agent Inbox Triage ← Invoice Runner queued · hop 1 of 3 queued

wake Firewall Auditor · 06:00 daily durable · survives reboot scheduled

Host restarted 02:41. 3 unfinished tasks recovered, none duplicated.

Routines

Ask once. It keeps happening.

"Check the backups every night." "Chase unpaid invoices every Monday at nine." "Watch that supplier portal and tell me when the price changes." A bot writes its own schedule, keeps running after you've logged off, and reaches you only when there's something worth reaching you about.

Interval, daily or weekly — in your host's local time, not a cron expression you have to decode a year later.
Durable firings — a missed window isn't a lost routine.
Alerts that mean something — bots are instructed not to report a quiet night. An alarm that fires daily is one nobody reads.

create_routine · list_routines · delete_routine · notify_user

routines · Night Watch

Backup verify every 15 min · 412 runs · 3 alerts in 30 days on

Morning note daily 07:30 · what changed overnight on

Supplier price watch weekly Mon 09:00 · opens the portal, compares, reports on

Certificate expiry sweep daily 06:00 · paused by you on 12 Sep off

notify_user · 02:16

db-02's last good backup is 31 hours old — the job is failing on a full disk. Worth fixing before tonight's run.

Teamwork

Bots hand work to each other — and know when to stop

A bot can see its teammates, send one a job, and go back to its own. The hard part isn't getting bots to talk. It's stopping them from talking forever.

Night Watchworking

Firewall Auditorneeds you

Inbox Triageidle

Invoice Runnerworking

Shift Reporterasleep until 07:30

+ New bota name and a job

What goes wrong elsewhere

Two bots thanking each other, all night

Auto-acknowledgement is the classic multi-agent failure: every message earns a reply, every reply earns a reply, and by morning you've burned a week of tokens on politeness.

Each message triggers an automatic answer
Loops prevented by asking the model nicely
Chains run until something falls over
No record of who told whom to do what

How NeuroBots does it

Hand-offs with a hop count and a hard cap

Every peer message carries its depth in the chain, and the mailroom refuses to deliver past the cap — enforced in code, not requested in a prompt. Bots don't auto-reply at all.

Fire-and-forget hand-offs: send, then get on with your own work
Hop count enforced by the host; your own requests always start fresh
Bounded group rooms when several bots need one thread
Every hand-off appears in both transcripts and the audit log

list_agentsWho's on the team, what they're for, and what they're busy with right now.

send_to_agent"You own the ledger — can you confirm invoice 4471 cleared?" Delivered durably, even if the recipient is mid-task or the host restarts.

RoomsA bounded group thread for the handful of jobs that genuinely need three bots and you in one place.

Guard rails

Real access calls for real controls

A bot with a shell, a mailbox and a firewall session is useful precisely because it can do damage. Everything below exists so that usefulness never arrives as a surprise.

Permission cards

Actions are graded by what they can do: reading is free, running a command asks, using a credential asks, anything destructive asks. You answer once, for this call or for the whole class — and you can lower a permission but never silently raise it past its ceiling.

Every call audited

Tool name, arguments, who approved it, what came back. The audit log is the host's, not the bot's — so "what did it actually do at 3am?" has an answer that doesn't depend on the bot's own account of itself.

Secrets stay with the host

Credentials live encrypted on the server. A bot requests a login by name and the host performs it. The password never enters a prompt, a transcript or a model request.

Confined to its own files

File paths from a model are untrusted input. Every path is checked twice — once lexically, once against the real filesystem — so neither ../ nor a planted symlink gets a bot out of its workspace or into a peer's.

Some things are simply refused

A short list of commands is rejected even when you approve them — because "Allow this change?" cannot honestly convey "the device comes back factory-default with no way in." An approval is only consent to what it can describe.

Off until you turn it on

No connector is live by default. Mail, credentials, screens, network devices — each one is a deliberate act of enabling, scoped to the bots that need it.

asa-edge-01 · change in flight

step 1 Read the house playbook asa_playbook → naming, ACL order, NAT rules

step 2 Arm the revert first reload in 10 — before a single line is applied

step 3 Ask you, with the exact lines 4 commands · diff shown · awaiting approval needs you

step 4 Prove it works, then make it stick packet-tracer passes → asa_save cancels the revert pending

If the change cuts management access, nobody has to drive to the office. The firewall un-applies it by itself.

Worked example

The firewall is the honest test of a bot

A bad line in a workspace file spoils a file. A bad line on the edge firewall takes an office offline — and the way it fails is by severing the very session you'd fix it from. So the firewall tools are built backwards from that failure.

The revert is scheduled before the change. A change that locks you out un-applies itself, with no human in the loop.
Saving is a separate, deliberate act. A bot has to come back and say "it works, keep it" — after proving it.
House rules are read, not assumed. Your conventions live in a playbook the bot must consult, and that you can edit from the UI.
A rejected command reads as a failure. A device that says no is reported as no — never dressed up as a success.

Cisco ASA ships today. The same pattern — read the rules, arm the undo, ask with the exact lines, prove before you save — is how every future device integration will be built.

Bring your own brain

The model is rented. The bots are yours.

Nothing above the model interface knows or cares which vendor you picked. Swap it, run it on your own GPU, or split work across both — without touching a single bot, tool or routine.

Hosted

Frontier models through the Anthropic API when you want the strongest reasoning available.

Entirely local

LM Studio, Ollama, vLLM, llama.cpp — on your own hardware, for data that cannot leave the building.

Swap without migrating

The adapter is the only thing that knows the wire format. Changing provider changes no bot, no tool and no schedule.

Walk away intact

Transcripts, memory and files are plain databases and plain directories on your disk. Leaving costs you nothing but the model bill.

Anthropic API LM Studio Ollama vLLM llama.cpp OpenRouter OpenAI-compatible endpoints

Better together

NeuroHive holds the context. NeuroBots does the work.

They're built as two halves of one idea. NeuroHive is the control room — projects, context, memory, secrets, the record of every decision. NeuroBots is the crew that acts on it, with hands on your actual systems.

NeuroHive

The context layer

Everything about a project on one page, and a memory that outlives whichever model wrote it.

Projects, briefs and decisions in one place
Context and memory that stay yours across model changes
Encrypted secrets, hosts, deployments, audit trail
Companies and teams, with scope inherited by anything that runs

Federated

NeuroBots

The execution layer

Bots that pick up a brief and go and do it — on the shell, in the inbox, on the portal, on the firewall.

A bot attached to a project inherits its context and its scope
Work it does flows back as project history, not a private chat log
Permissions and audit roll up to the same record
Routines keep a project watched after the humans log off

One scope, inherited

A bot working on a NeuroHive project sees that project's context and nothing else. Scope is set once, at the top, and carried down — not re-typed per bot and hoped for.

One record

Approvals, tool calls and outcomes land in the same audit trail as the rest of the project — so the bot's night shift reads as part of the work, not a separate system you have to go and check.

Use either alone

NeuroBots runs perfectly well on its own, and NeuroHive doesn't need bots to be useful. Run one, then add the other when it earns its place.

NeuroBots ships as an add-on to NeuroHive. The federation surface is in active development — the honest status of every piece is below.

In practice

From "someone should be watching that" to a bot that is

Create

Name it, give it a job, and it is live. Seconds, not a deployment.

Brief

Tell it what good looks like, in plain words. Correct it once; it remembers the correction.

Approve

The first few real actions come to you as permission cards. Grant the classes you're happy with.

Let it run

It schedules itself, works while you don't, and only interrupts you when it matters.

Where it actually is

What ships today, and what's still being built

We'd rather you buy the real thing than the brochure. This table is kept in step with the repository, and a pilot gets you the left-hand column — not a promise about the right.

CapabilityStatus

Bots with profiles, durable private transcripts and isolated storage Survives restarts; one bot can never read another's record. shipping

Hand-offs, durable wake, retry and boot recovery Exactly-once delivery enforced by the database, not by convention. shipping

User and background lanes, with real interruption Your turn pre-empts everything; stopped work genuinely stops. shipping

Bounded group rooms Several bots and you in one thread, with a cap on the chatter. shipping

Scoped memory with budgeted recall Tiers and scopes live; project-wide scope is being wired end to end. shipping · extending

Shell, files, screens, browser, mail, credentials, firewall 31 audited tools, each behind a permission class. shipping

Local agent for systems in your own environment Lets bots reach and act on your own machines, under the same permission classes. shipping

Permission cards and audit logs Live for every class; outbound-mail policy is being re-graded so it can be allowed deliberately rather than refused outright. shipping · extending

Hosted and local model adapters Anthropic API and any OpenAI-compatible server. shipping

Per-bot tool enablement from the UI Authorization and audit run on every call today; the per-bot switchboard is next. in build

Shared skill & workflow library Reusable house procedures a bot loads on demand, instead of being re-explained. in build

NeuroHive federation Projects, scope and audit shared across both products. in build

Remote bot agent Place a bot anywhere — run it close to the systems it works on. planned

NetYard bridge Site inventory and live device state available to bots, under the same permission classes. planned

Images in bot-to-bot messages A bot can describe a screenshot today; passing one to a peer is queued. planned