Core Loop Agents
Automate the full feedback-to-PR pipeline with governed AI agents. From user feedback to shipped code, with human oversight at every step.
Overview
The Core Loop connects every stage of the feedback-to-code pipeline into a single governed flow. Each stage feeds into the next automatically, with approval gates and audit trails built in.
Intents
An intent is a structured “job to be done” derived from an accepted improvement. When you accept an AI-generated improvement, Lupr extracts a precise intent that an agent can act on — scoped, constrained, and risk-tiered.
What each intent contains
jobToBeDone
A clear, imperative statement of what the agent should accomplish.
acceptanceCriteria
A list of conditions that must be true for the task to be considered complete.
constraints
Boundaries the agent must not cross — files to avoid, patterns to preserve, etc.
riskTier & evidenceSummary
The risk classification and a summary of the feedback evidence supporting this change.
Risk tiers
| Tier | Label | Approval | Max files | Required receipts |
|---|---|---|---|---|
| TIER0_DOCS | Documentation | No | 5 | diff |
| TIER1_LOW | Small changes | Yes (pitch owner) | 20 | difftest_results |
| TIER2–4 | Reserved | — | — | — |
How to trigger intent extraction
Manually from the project page
Accept an improvement, then click "Extract Intent" to create an intent immediately.
Automatically via cron
The system periodically scans for accepted improvements that don't yet have intents and extracts them automatically.
Approvals
Approvals ensure that a human signs off before an agent starts writing code. The approval requirement is determined by the intent's risk tier.
When approval is required
TIER0_DOCS bypasses approval
Documentation-only changes skip the approval step entirely and proceed straight to agent task creation.
TIER1_LOW and above require approval
Any intent that modifies code must be reviewed and approved by the pitch owner before an agent task is created.
Approval flow
Request created
An approval request is automatically generated when a TIER1+ intent is ready.
Pitch owner reviews
The project owner sees the intent details — job to be done, acceptance criteria, constraints, and risk tier — and decides whether to proceed.
Approve or reject
The owner approves (with optional notes) to greenlight the agent, or rejects with a reason. Rejected intents are archived.
72-hour expiry: Pending approvals expire after 72 hours. Expired approvals don't block the intent — you can create a new approval request at any time.
Agent tasks
Once an intent is approved (or bypasses approval), an agent task is created. The task tracks the full lifecycle from issue creation through to PR resolution.
Task statuses
Task lifecycle
Task created — GitHub issue opened
A GitHub issue is created in the connected repository with the full intent details: job to be done, acceptance criteria, constraints, and evidence summary.
Agent picks up the issue
The coding agent begins work on the issue. The task status moves to RUNNING.
PR opened — task moves to PR_OPEN
The agent opens a pull request on a branch with the lupr/ prefix. The task links to the PR for review.
PR resolved — final status
If the PR is merged, the task moves to SUCCEEDED. If the PR is closed without merging, the task is marked FAILED.
Branch naming: All agent branches use the lupr/ prefix, so you can easily identify agent-created branches in your repository.
Receipts
Every completed agent task produces a receipt — a structured record of what the agent did, what changed, and whether the work met the tier's policy requirements.
What a receipt contains
Diff summary
A summary of all files changed — additions, modifications, and deletions.
Test results
Number of tests passed, failed, and skipped. Includes output from the test runner.
Tool call log
A full record of every tool call the agent made — file reads, writes, shell commands, and searches.
Policy decisions
A pass/fail breakdown of each policy check — max files, required receipts, allowed tools, and more.
Receipts are validated against the tier's policy requirements. For example, a TIER1_LOW task must include both a diff and test results. If any required receipt is missing or validation fails, the task is marked as FAILED even if the PR was opened.
Policy
Policies govern what agents are allowed to do. Each risk tier ships with sensible defaults, and you can customize them per project.
Default policies by tier
| Tier | Max files | Approval | Required receipts |
|---|---|---|---|
| TIER0_DOCS | 5 | None | diff |
| TIER1_LOW | 20 | Pitch owner | diff, test_results |
| TIER2–4 | — | — | — |
Policy overlay
You can customize policies per project from Settings. Project-level overrides are merged on top of the tier defaults — anything you don't override keeps the default value.
What you can customize
Allowed tools
Restrict which tools the agent can use — for example, disallow shell commands or limit to read-only file access.
Max files changed
Set a hard limit on how many files the agent can modify in a single task.
Required receipts
Specify which receipt types must be present for a task to pass validation — diff, test_results, tool_call_log, etc.
Branch prefix
Override the default lupr/ branch prefix with a custom prefix for your repository conventions.
Tracing & audit
Every agent action is fully traceable. Lupr maintains a complete audit trail so you always know what happened, when, and why.
Full action trace
Every step the agent takes — from reading files to writing code to running tests — is recorded with timestamps and context.
Tool call logging with PII redaction
All tool calls are logged in detail. Sensitive data (API keys, tokens, personal information) is automatically redacted before storage.
Project audit log
All events — intent creation, approval decisions, task status changes, receipt validation — feed into a unified project audit log accessible from your dashboard.
Governance by default: Tracing is always on and cannot be disabled. This ensures every agent action is auditable, regardless of the risk tier.
Next steps
Now that you understand the Core Loop, explore related documentation: