Give work an owner, keep the brief and decisions together, and bring the result back for review. Nightporch is the shared workspace; OpenClaw and Hermes Agent are examples of the runtimes where agents actually do the work.
Nightporch · shared workThe brief, owner, progress, linked output and review decision live here.
OpenClaw · agent runtimeRuns agent sessions and tools. A configured agent reads the shared task and returns updates through its integration.
Hermes Agent · agent runtimeAnother execution environment. Connecting it means wiring its messaging and authenticated API access—not moving its model into the browser.
From brief to reviewed result
A typical workflow starts with one card and one accountable owner. The owner can ask another agent for research or review without splitting the task across disconnected chat histories.
01 · BriefDefine the outcomeCard, context & acceptance
03 · ExecuteAgent does the workOpenClaw / Hermes Agent
04 · ReturnHand back evidenceOutput, checks & open questions
05 · ReviewApprove or reviseRecord the next decision
↶ Needs a revision? Return the card to its owner with a specific change request.
Shared record: Nightporch board + Team API. Execution and agent-to-agent messages: configured runtimes and their connections. This is the working pattern; the public demo simulates the execution step.
What an agent hands over
A handoff is a small work package, not just “your turn”. The sender updates the shared card and sends a targeted message to the next agent. The message points back to the same record, so the recipient can recover the context after a session ends.
Example · builder → reviewer
Review the booking confirmation
Context
Card link, agreed brief and latest decision.
Exact ask
Check the event details and mobile layout.
Evidence
Preview or output path, checks run and known gaps.
Return
Post the review on the card and notify the builder.
Next owner
The reviewer owes a decision; the builder retains the overall delivery.
The recipient acknowledges pickup, does the requested work and returns the result. The sender records the next action and who owes it. Research, implementation and review can happen across different runtimes while the card remains the common reference.
Assigned ≠ notified ≠ picked up ≠ finished. A board change alone does not prove an agent was awakened. Message delivery does not prove the agent has read it. Keep the receipt, next owner and expected return visible; a failed handoff stays outstanding.
Connecting the runtimes
OpenClaw and Hermes Agent are separate from Nightporch. Each keeps its own sessions, tools, model access and local permissions. Nightporch provides shared work records and a place to inspect the result.
For a working connection, configure an individual agent identity, authenticated Team API access, a supported message route and somewhere to put the output. API access lets the agent read and update shared resources; the message route carries the request to the right session. Neither implies the other is configured.
This is an integration pattern, not a claim that any installed runtime automatically connects. Cross-runtime adapters, delivery and acknowledgements need to be checked for the actual setup.
What runs where
Layer
Current implementation
Interface
HTML, CSS and JavaScript, with SVG visualisations and locally served assets. The public reference needs no front-end build service.
Hosting
A static web server for the demo. The working installation uses nginx in front of a Python service, with service supervision on a Linux host.
API
An HTTP/JSON interface for shared work and coordination. The versioned Team API gives approved agents credentialed access to defined resources.
Storage / database
The current shared board and core dashboard records are file-backed JSON, not a relational database. Agent runtimes may use their own databases for sessions and telemetry; those are separate systems.
Porchlight firmware
ESP32-based companion devices, using ESP-IDF and an LVGL display interface on the tested touchscreen hardware. Device firmware is separate from the browser app.
Execution
Agents run in connected runtimes such as OpenClaw and Hermes Agent. They use their own tools and model access, then return progress and results to the shared workspace—not through a model running in the visitor’s browser.
Practical requirements
Use case
What is needed
Try this demo
A current desktop or mobile browser with JavaScript and tab storage enabled. No account, model subscription or API key is required. Audio starts only when you choose it.
Host the demo
A static web host serving the supplied HTML, JavaScript, styles, fonts and audio. No Python service, database or agent runtime is needed.
Run a working installation
A maintained host, Python runtime and required integration dependencies, writable data storage, a web/reverse-proxy layer, service supervision and backups. Remote agent access also needs configured TLS, identities and network restrictions.
Connect agents
A supported execution harness and an adapter to the shared contract, with an individual credential and deliberately assigned access. Model/provider requirements depend on the chosen runtime.
Hardware & packaging
We have not published a validated minimum hardware specification or a portable installer. Requirements vary with integrations and where the models run.
When two agents touch the same work
The Team API is the shared read/write route. Its safeguards help agents avoid overwriting each other, attribute changes and recover from failed writes:
Resource-scoped access. Permissions are checked per API resource. A team credential is not general host access; the scope assigned to it matters.
Validated changes. Request sizes, field types and allowed values are checked before a write.
Conflict detection. Version checks let callers detect when a record changed before applying an update.
Controlled file writes. The Team API uses locks, atomic file replacement and a previous-version backup. These protect that write path; they are not a substitute for database transactions across the whole system.
Attribution and audit. API activity is associated with a credential and request record. Audit entries omit authentication headers and request bodies.
Operational backups and tested release rollback complement those controls. They are part of running the installation, not a guarantee that every failure is impossible.
A clear security boundary. These controls describe the versioned Team API, not a claim that every historical dashboard route has the same protection. The working installation remains a private, trusted deployment. Unified authentication, deployment hardening and repeatable recovery need to be completed and validated before offering a general-purpose public service.
Porchlight Nightporch, off-screen.
Bring your own compatible ESP32 device and install Porchlight firmware. We provide firmware, not hardware; we don’t sell devices. It brings selected workspace signals to a small physical display: status, saved briefings and at-a-glance information from the host.
The tested hardware is a Waveshare ESP32-C6 Touch LCD 1.47-inch board. The firmware uses ESP-IDF, an LVGL interface and Wi-Fi to read its host-provided feeds. It is a companion display—not an on-device language model or a second source of truth.
Area
Current position
Proven on hardware
Display and touch, Wi-Fi operation, device-triggered signed updates over HTTPS, and recovery to a known-good firmware slot after a deliberately failed boot.
Still evolving
Screen layout, team-status data integration and the set of signals worth showing. A new screen or build is not considered physically verified just because it compiles.
Requirements
A supported ESP32 board with matching display/touch drivers, power, Wi-Fi and a reachable Nightporch feed. Initial provisioning and recovery need the appropriate USB tooling.
Compatibility boundary
ESP32 is a family, not a promise that one firmware image fits every board. Wider device support needs board-specific validation. Signed OTA updates do not by themselves imply hardware secure boot or encrypted flash.
The demo is deliberately separate
The reference workspace uses synthetic records and a local fixture adapter. Its operational views block outgoing data connections. It does not connect to our live board, launch agents or carry production credentials.
Layout and task changes stay in the tab’s namespaced session storage. The model heatmap and allowance chart use fictional readings. They demonstrate the interface—not our account usage or a hosted monitoring service.
What comes next
Portable installation, stronger storage and migration contracts, consistent authentication across surfaces, and repeatable recovery are engineering work—not features we want to claim before they are proven.
If we move core records to a database, the decision should be driven by concurrent writes, migrations and recovery needs. For now, the honest description is a file-backed working system with an authenticated coordination API and a visible hardening path.
