Sedrus Take-home · Engineering

Sedrus take-home

Client Document Intake

This project is open-ended on purpose. We want to see how you build an AI agent, how you make product decisions when the spec is incomplete, and how you change course when the requirements do.

Timebox
About 4 hours. If you run out of time, write down what's missing and stop.
Model costs
We'll give you an API key for the agent you build, not for your coding tools.
Stack
Any language, any model provider. Use the AI coding tools you normally use.
Submission
A link to your repo, by the date we gave you.

The problem

Ledgerline Wealth is a growing registered investment adviser (RIA) that has never used generative AI.

Client families send Ledgerline their estate documents a few at a time, over months or years: a trust agreement when they sign on, a power of attorney a few weeks later, an amendment years after that, a death certificate when a family member dies. Today an analyst reads each document and updates the records by hand: who the trustees of each trust are, who can act for whom, and who has died.

Mistakes are expensive. If the records list the wrong trustee, the wrong person can move a family's money. If two people are merged into one, someone gets access to an account that isn't theirs.

Ledgerline would rather the tool ask a human than guess.

What you get

Three batches of documents: documents/batch_1/, documents/batch_2/ and documents/batch_3/. Fill in: document format, e.g. "Each document is a plain-text file." Treat the batches as arriving in order, weeks apart.

The documents are synthetic, but they read like the real thing. Expect the same person to appear under different forms of their name, and later documents to refer back to earlier ones.

What to build

A CLI agent that keeps Ledgerline's records of trusts and people correct as documents arrive. Documents go in; the agent works out what each one says and updates a state file that persists between runs. It does two things, named however you like:

Ingest documents

ingest <file-or-folder>
For each document, the agent works out what kind of document it is, what it establishes, and how that changes the records. Where it can't be sure, it records a question for a human instead of guessing. Ingesting the same document twice should change nothing.

Get entities

entities
Prints the current records: every person and every trust, the roles that connect them, the document each fact came from, and whatever is waiting on a human.

State lives in a JSON file. Its shape is yours to design; the design doc asks you to defend it.

Deliverables

A link to a git repo containing:

  1. The CLI, with a README covering setup and the commands to run.
  2. The state after each batch: state_after_batch_1.json, state_after_batch_2.json, state_after_batch_3.json.
  3. An agent log: for each document, the tool calls and the reasons the agent gave.
  4. A design doc (1–2 pages) covering:
    • Your loop: the tools the model has, what your code checks outside the model, and how a run stops.
    • Your state schema, and why you shaped it that way.
    • How you decide two mentions are the same entity, and when you refuse to decide.
    • What happens when a newer document contradicts an older one, or documents arrive out of order.
    • What you would and wouldn't trust this tool to do without a human.
    • Questions for Ledgerline: what you'd ask the client before going to production. The questions matter to us as much as the answers you'd assume.