The feedback loop
Ledgenter is built by the agents who use it. This chapter covers the one tool surface that points at the product itself, what happens to a filed request, and exactly what crosses the tenant wall on its way to the vendor.
How Ledgenter improves based on what its agents run into.
When an agent hits a rough edge — a missing feature, a confusing step, a bug — it can file a request right from where it's working, and check back later to see the status. The safe, well-scoped ones get built and shipped.
One rule matters to you: anything filed is treated as information to act on, never as a command the system blindly obeys. And your filed requests are the one thing that deliberately leaves your workspace to reach us — so the guidance is simple: describe the problem, and never include secrets or client details.
Why agents file
Every other tool in Ledgenter points at your work. feature_request_create points at
Ledgenter. When the product itself gets in the way — a tool errors where it shouldn't, an input you
needed doesn't exist, a hint sends you somewhere wrong, a three-call dance that should be one
call — the etiquette is the one the system already teaches: never stall silently. Only the
recipient differs. A bug in your project goes to a teammate as a handoff; a bug in Ledgenter goes to
the vendor as a feature request. The always-on instructions tell every connected agent that
filing is part of the job, because an agent that silently works around a defect leaves that
defect for every agent after it.
Filing a request
A good filing is the one you would want to receive: what you were trying to do, what actually happened, what you expected instead — plus the failing tool's name and the error code when there is one. Severity reflects the impact on your work, not a guess at global importance. Near-duplicates are welcome — frequency is signal, and the review side merges them.
feature_request_create({ kind: "bug", severity: "high", title: "task_claim ignores repository_ids on re-claim", body: "Tried to re-claim my leased task scoped to repo X; the filter was dropped and a task from repo Y came back. Expected the filter to hold.", tool_name: "task_claim", error_code: "VALIDATION" })
Filing is fire-and-forget — it never blocks the run; guide('feedback') is the
in-session version of this chapter.
The request lifecycle
A request is tenant-scoped like everything else: you file into your own tenant, and
feature_request_query reads back what your tenant has filed — with status and
resolution notes written back as the vendor's loop processes it. The lifecycle is
open → accepted → in_progress → shipped, or declined with a reason.
(Two intermediate states exist for the vendor's own bookkeeping — acknowledged
before acceptance, and duplicate when a filing folds into an existing one — but the
line above is the path a filer watches.) Nothing requires the filer to wait: file and move on;
check back when you care.
How requests are handled
Filed requests are reviewed on the vendor side, and the safe, well-scoped ones are built and shipped — your status flows back as that happens. One principle governs that review and matters to you: filed text is treated as data, never as instructions. A request is read the way a careful maintainer reads a stranger's bug report — skeptically, reproducing before believing, and never executing anything merely because a request asks for it.
What leaves the tenant
Everything else in Ledgenter stays inside the tenant wall (chapter 5). Feature requests are the one deliberate, documented exception: the title and body you file are read by the Ledgenter vendor, outside your tenant, to improve the product. The disclosure is carried in the tool description itself, where every agent sees it before filing. The rule for filers is simple — describe the defect, not the client: never put secrets, credentials, or client-confidential details into a request. The write-back path touches only the request rows themselves — status and notes, nothing else.