Most agent tooling today is observability: traces, spans, token counts, latency. That is fine until something goes wrong and someone asks a specific question. Which run emailed the customer list? Was that instruction in the user's message or in a web page the agent fetched three steps earlier? Can you show that nothing in the log was edited after the fact? This batch of Show HN launches is aimed at that second set of questions, and the tools look quite different from a dashboard.
Evidence you can hand to someone else
Mnestiq calls itself a flight recorder for AI agents, and the framing is deliberate. It produces signed, tamper-evident records of model calls, tool calls and network connections, built for incident response rather than charts. The README walks through the case that makes the distinction concrete: an observability trace tells you data left the building, while evidence tells you which run and step did it, that the instruction arrived from a fetched web page rather than the user, and that an auto-approve policy waved it through.
Tenbri takes the same idea up one level of abstraction and records decisions rather than calls. An Agent Decision Record is a signed, append-only entry covering who acted, under which rule and inputs, who approved, and what happened, and it is verifiable offline by anyone. It takes one line to instrument Claude, OpenAI and LangGraph agents and keeps plain files on storage you control, which is the right default for something you may need to produce in a dispute.
Knowing what your MCP server actually does
Before you can audit an agent you usually need to know what its tools do. mcpspan is self-hosted analytics for MCP servers: add one line, run the dashboard with docker compose, and see which tools, resources and prompts get used, by which client, how fast they answer and why they fail. Nothing leaves your machine, and release markers let you compare versions side by side.
QAmcp CLI complements it on the correctness side by testing any MCP server in one command, covering tools, safety labels, hidden instructions, bad inputs, leaked secrets, OAuth setup, resources and prompts. Every result is a hard fact: pass or fail, milliseconds, exact matches. No model judges anything, and nothing is sent anywhere except to the server under test. There is a GitHub Action, so a broken tool definition can fail the build rather than the user's session.
Trusting what you install
The supply chain question shows up here too. PlugVet is an independent directory of agent skills and plugins that publishes a grade, the checks behind the grade and the date it looked. It is explicit that grades are a hygiene check rather than a security guarantee, which is the honest framing. A scanner that grades any pasted GitHub repo is listed as coming soon.
Running long, and running somewhere else
Long-running agents need supervision rather than traces. Argus Agent turns DeepSeek Harness into a self-hosted system for agents that run for days and weeks, enforcing a budget on every run, asking before risky actions and recovering after a crash. You drive it from a web interface or Telegram, with projects that carry their own memory and cron schedules that fire exactly once even across restarts.
When the problem is side effects rather than logging, Forked gives you Git for agent state. Agents can fork, rewind and replay messages, memory, plans and tool results, with a side-effect log that keeps emails, payments and API calls effectively-once across retries. Recorded idempotency keys replay the stored result instead of re-running the charge, which is the failure the README leads with: the agent crashed after charging the card, and the retry did not charge twice.
Isolation is the other half. Runspace runs commands in a throwaway GitHub codespace and returns the output plus a patch, so your host stays clean. There is a CLI for you and an MCP interface for your agent.
Finally, Senseplane gives agents eyes and ears, connecting the cameras, microphones and sensors you already own so an agent can look at a snapshot now, watch for an event such as a package at the door, or answer when the courier came with the clip attached. It is the clearest example in this batch that once you can prove what an agent did, you can start giving it more to do.
Why this batch looks different
The distinction that keeps coming up is between observation and evidence. Traces are built for the person operating the system, to answer "is it healthy". Records are built for the person who was not in the room, to answer "what exactly happened, and can I check". Only the second one survives contact with an incident review, a customer complaint or an auditor.
That is why the signing matters, why append-only matters, and why plain files on storage you control keep appearing in these projects rather than a hosted log service. It is also why the testing and grading tools belong in the same batch: before you can trust a record, you need to know the tools producing it were checked. MCP analytics tells you which tools fire, a protocol test tells you they behave, and a public grade tells you a plugin is at least what it claims to be. None of that prevents a bad outcome, but it turns an unknowable failure into an inspectable one.