tieout: close-keeper

Ties out close workbooks quietly and only pings you when a real decision needs your judgment

Comment

Inspiration

The financial close is full of work that is repetitive but still requires judgment: tying out spreadsheets, finding the right source value, checking whether an answer is trustworthy, and deciding what to do when the evidence does not line up.

The judgment is scarce; the busywork isn't.

We built close-keeper around a simple principle: an agent should absorb the mechanical work while protecting the moments where a finance professional actually needs to make a decision. If the system cannot verify an answer, it should not guess. Blank is an answer, never a guess.

Our goal is to let someone run a close without spending another night manually chasing spreadsheet cells.

What it does

close-keeper is a Strands Agents SDK agent for finance professionals running a monthly close.

It works through close workbooks in the background:

  1. Classifies the answer range.
  2. Generates or looks up the expected value.
  3. Verifies the result.
  4. Repairs the answer when possible, up to three times.
  5. Records every answer it can verify.
  6. Leaves anything it cannot verify blank and routes it to a human with source-row evidence.

Approved values are written through a single recorded path that persists the decision before touching any workbook cell.

The agent also has governed business memory. New rules follow a record → propose → validate → activate lifecycle. Validation replays labeled cases covering positives, hard negatives, scope boundaries, and conflicts, with zero regressions allowed before activation.

The same governance is expressed as Cedar policies at the Amazon Bedrock AgentCore Gateway boundary. This means that even if the agent loop were compromised, it still could not write an unauthorized decision or activate an unvalidated rule.

The agent loop is intentionally thin. The enforcement lives in the tools.

The repository includes an 11-tool agent in close_keeper/, the underlying tieout harness and governed SQLite memory, a marimo console, and a live demo at close_keeper/demo_app.py that runs the full flow with synthetic data and requires no account. The AgentCore runtime entrypoint and Cedar policies are included for the deployment track.

How we built it

We built close-keeper around the Strands Agents SDK, with the agent responsible for deciding which governed tool to call rather than directly implementing business enforcement.

The core tieout machinery provides the deterministic substrate underneath the agent: workbook handling, answer generation and lookup, verification, repair, evidence capture, and governed persistence.

Business memory is deliberately treated as a governed capability rather than something the agent can freely modify. A proposed rule must be recorded, replayed against labeled cases, validated without regressions, and only then activated.

For deployment, we carried those boundaries out to the Amazon Bedrock AgentCore Gateway using Cedar policies. This gives us defense in depth: application-level tool controls are reinforced by policy at the gateway boundary.

We also built the live demo around synthetic close data so the complete workflow can be explored without requiring access to real financial systems or an external account.

Challenges we ran into

The hardest part was not getting an agent to fill in a spreadsheet. It was making sure the agent couldn't quietly make an unjustified decision.

Finance close work has an uncomfortable failure mode: a plausible-looking number can be much more dangerous than an obvious error. That led us to make uncertainty a first-class outcome. When verification fails, the system leaves the answer blank and escalates with evidence instead of trying to be helpful by guessing.

We also had to think carefully about where enforcement belongs. Putting all the rules into the prompt makes them vulnerable to agent behavior. Putting them only into application code leaves a gap at the boundary. We therefore pushed enforcement into governed tools and reinforced the critical permissions with Cedar policies at the AgentCore Gateway.

Finally, business memory introduced another challenge: learning must not become uncontrolled self-modification. We designed activation as a governed lifecycle with replay cases and a zero-regression requirement.

Accomplishments that we're proud of

We're proud that close-keeper is more than an agent that can manipulate a workbook.

It has a complete governed workflow for the financial close:

  • Verification before writing — the system does not treat a plausible answer as a verified answer.
  • Blank instead of guessing — unresolved cells remain blank and are routed to a human with source evidence.
  • Recorded decisions — approved values go through one persisted decision path before a workbook cell is changed.
  • Governed business memory — rules move through record, proposal, validation, and activation rather than being silently learned.
  • Adversarial replay validation — proposed rules are tested against positive, hard-negative, scope-boundary, and conflict cases.
  • Zero-regression activation — a rule cannot activate if it breaks an existing labeled case.
  • Defense in depth — Cedar policies at the AgentCore Gateway provide an additional boundary against unauthorized writes or rule activation.
  • A runnable demo — the full flow works on synthetic data without requiring an account.

Most importantly, we think the design captures an important distinction for professional agents: automation should reduce busywork without automating away accountability.

What we learned

We learned that the interesting part of a professional agent is not how much work it can perform autonomously. It is how clearly it knows what it is allowed to do.

For financial workflows, trust comes from making the boundary between automation and judgment explicit.

That changed how we approached the architecture. Instead of making the agent increasingly powerful, we made the tools increasingly governed. Instead of treating uncertainty as a failure, we made it an explicit outcome. Instead of allowing memory to evolve implicitly, we made learning go through validation and activation.

We also learned that a good human-in-the-loop experience is not simply "ask a human whenever something goes wrong." The system should do as much verification as it safely can, then surface the remaining decision with the evidence needed to resolve it quickly.

The result is an agent that aims to be quiet when everything is correct and very clear when human judgment is actually required.

What's next for tieout: close-keeper

Next, we want to take close-keeper from a strong governed prototype toward a system that can sit alongside a real close process.

That means expanding the workbook and accounting-system integrations, increasing the library of replay and hard-negative cases, improving the evidence presented for human review, and making the governed memory workflow easier for finance teams to operate.

We also want to explore richer close orchestration: letting close-keeper coordinate more of the repetitive work across a close while preserving the same principle at every boundary.

The long-term goal is simple:

Let the agent handle the spreadsheet work. Let the human handle the judgment. Make the boundary auditable.

Built With

Share this project:

Updates

Submission history