How Nitejar Works

Nitejar turns inbound messages into work, routes that work to the right agent, executes tools, and records the entire path as receipts.

For operators, the important distinction is:

• Command Center, Company, Work, and Inbox are operating surfaces.
• Activity is the receipt surface.

The steps below describe the receipt pipeline that powers Activity. You usually inspect these details only after a higher-level surface tells you something needs attention.

1. Inbound event

An external channel (Telegram, GitHub, Slack, Discord, a custom webhook) sends an HTTP request to Nitejar.

Where to verify: Plugins. Each plugin instance shows its webhook URL and recent webhook activity.

2. Work item creation

The parsed message becomes a work item in the database with status pending. This is the durable backend primitive Nitejar uses to queue, deduplicate, and inspect work.

Where to verify: Activity. The work item appears immediately with status pending and a timestamp.

3. Queue and dispatch

The queue claims the work item and decides when to start a run. It does not fire every event immediately -- queue mode, debounce, and in-flight state affect when the agent actually runs.

Where to verify: Activity > click a work item. The timeline shows the gap between "work item created" and "run dispatched".

4. Prompt build and inference

The runtime builds the agent's system prompt from its configuration, soul, skills, memory, and tool definitions. It then calls the model and loops through tool use until the run is complete.

Where to verify: Activity > click a work item > Run timeline. Every inference call shows the model used, token counts, latency, and cost. Every tool execution shows the tool name, arguments, and result.

5. Delivery

The agent's response does not go directly to the channel. It lands in the effect/delivery layer, which sends it back through the originating plugin.

Where to verify: Activity > click a work item. The response delivery entry shows the outcome (sent, failed, unknown), the external message ID if the channel returned one, and the delivery timestamp.

6. Receipts everywhere

At every step above, a receipt is written. Work item creation, run dispatch, each inference call, each tool execution, and response delivery all produce inspectable records.

Open Activity and click any work item. The full timeline is there: webhook received, work item created, run dispatched, inference calls, tool executions, response delivered. Each entry has timestamps, and cost rolls up to the work item and agent level. You can also check Costs for aggregate spend across agents and models.

Why the app is split the way it is

The product intentionally keeps high-level management separate from receipts:

• use Command Center for urgent attention
• use Company for structure and staffing
• use Work for goals, tickets, and heartbeats
• use Inbox for human follow-up
• use Activity when you need the underlying proof

That separation keeps the product readable. The receipts stay inspectable without taking over every screen.