Environment for bond monitoring over timeDissei / Live work / Workflows

Can an AI agent monitor a bond as the facts change?

An agent follows one bond inside a bank. Each dated update changes part of its working file and sends work to compliance, legal counsel, portfolio management, the credit committee or investor reporting. When later evidence lands, it has to revise what changed and keep what still holds.

Jump to pilot results In progressEarly pilot on one real case and one synthetic task family.

An agent on the bond desk

Most evaluations ask one question once. Monitoring a bond runs for years: results, new financing, amended terms, then a request that changes part of the picture. This environment keeps that shape and marks four checkpoints on it: Assess, Analyse and Commit on the review date, then Reassess when later evidence lands.

Bond updates, in date order
  1. Year 1Acquisition financing announced
  2. Year 1Bond issued
  3. Year 1Amended terms approved by bondholders
  4. Year 1Annual report published
  5. Year 2New financing, more bonds placed, buyback
  6. Review dateLatest annual report. Is the evidence enough?S1 Assess
  7. Review dateCalculate and reconcileS2 Analyse
  8. Review dateFreeze the decision and its evidenceS3 Commit
  9. LaterWaiver request and redemption noticeS4 Reassess

The order of updates follows the real case used in the pilot. Names, dates, amounts and identifiers are removed.

  • Dated evidence

    Each case is a versioned financial file. The agent sees only the evidence available on each checkpoint date. Later documents stay sealed until their date.

  • A workspace that persists

    Notes, calculations, spreadsheets and drafts carry from one checkpoint to the next, so the agent can build on its own earlier work instead of starting again.

  • Real tools

    The agent searches and reads evidence, works with files and runs Python in an isolated sandbox. Recommendations never execute a financial transaction.

How it works

Every criterion is a plain yes or no question about the work, checked against cited evidence. A criterion that fails keeps its weight in the total, so missing work counts against the score.

Pilot results

These are early pilot runs, not a benchmark. There is one real source case, so the number of independent cases is one. Do not read a ranking into these rows.

Real source case

A European high yield bond issuer facing a covenant waiver decision, with evidence dated 2024. Development split. Graded by the historical grader 2.0.0, with Grok 4.6 as the fixed judge. That grader was not calibrated.

Real source case, historical grader, reward out of 100
ModelFirst decision, of 60Update, of 40QualityRewardReward, 0 to 100
Kimi K2.5Completed, 24 turns45105554.5
Claude Sonnet 5Output was truncated, 27 turns4504545
DeepSeek V3.2Completed, 37 turns30205041
Kimi K2.5Invalid model response after one turnUnknownUnknownUnknownUnknownNo score
Kimi K2.5Run finished, grading unavailable after retriesUnknownUnknownUnknownUnknownNo score

Quality is the first decision score plus the update score. Reward is quality after debits and penalties. Two runs have no score and are shown as unknown, not zero. Two further runs failed before starting and produced nothing to grade.

Same trace, regraded later

The first Kimi K2.5 run above was regraded with the newer yes or no criteria. The model was not run again. The criteria were written after that run and have not been calibrated, so this is a separate reading of one trace, not a new result.

Same trace regraded with yes or no criteria, reward out of 100
ModelFirst decision, of 60Update, of 40QualityRewardReward, 0 to 100
Kimi K2.5, same traceRegraded with Boolean criteria written after the run5005033

Quality 50, less a debit of 2 and handling penalties of 15, gives a reward of 33. The original reading of 54.5 is kept above.

Synthetic task family

An engineering check, not a benchmark. 4 resolved runs of one synthetic task family with Kimi K2.5 all scored 100. One more run could not reach the model and is unknown. These runs show the pipeline works end to end. They are not independent cases.

What this does not show yet. Carrying work across dates has not yet been shown to help. No run so far compares an agent with its earlier work against the same agent without it.

What comes next

These are plans and design targets, not results.

  • More cases, with a held out set kept for evaluation only.
  • Diagnostic variants that should end at the first checkpoint, to test whether the agent knows when to stop.
  • A paired test of whether carrying work across dates helps: the same model at the last checkpoint, once with its full earlier work and once with only the current evidence and decision, compared on the update score alone.
  • Checks on the grader itself, against expert labelled pairs, seeded errors and negative controls, before any score is used for training.

Test your agents on
work that changes over time.

Cases, criteria and run records stay private. Talk to us about running Workflows on your agents under an agreement.