I write the specs — and I build the tooling that makes those specs cheaper to get right. Right now that means a hybrid team of people and agents, and I spend a lot of time on the agent lifecycle so the humans on the team actually get faster.

At Zeta, I run four consumer programmes as product leader, with a team of twelve: a sub-prime credit card live in operations in the UK, two credit cards in the US, one of them semi-prime and in build, and a US checking account. Two regulated markets, one team. Before Zeta: Mu Sigma, a founder stint at Parentof, Director of Product at Niyo. IIM Indore. Fourteen years: decision sciences, then edtech, then fintech.

How an agent or retrieval system goes from idea to something my team trusts.

flowchart LR
  subgraph D["Define"]
    direction TB
    A["Write the evals<br/>with the spec"] --> B["Derive the contract<br/>from the data<br/>strict output schema"]
  end
  subgraph R["Build"]
    direction TB
    C["Boring baseline,<br/>instrumented"] --> E["Observe retrieval<br/>top-K, rerank scores"]
    E --> F["Context: decide<br/>what to leave out"]
    F --> G["Cite or decline"]
  end
  subgraph S["Ship"]
    direction TB
    H["Judge one dimension<br/>at a time"] --> I["Human gate before<br/>anything that writes"]
    I --> J["Reversible: dry run,<br/>read-back, rollback"]
  end
  B --> C
  G --> H
  J -.-> A

Code means clone it and run it. Product definition means the artefacts that define a product before anyone builds it. Write-up means an engineering account of a system that runs on internal or client data, where the architecture and the failure modes are public and the corpus and deployment are not. Every write-up says so at the top.

Roughly in the order I would want them read.

• superset-bi-agent · Code. Builds and QCs Superset dashboard suites for card programmes, deriving each engagement's stage ladder from a transition matrix on live data. It exists because the stage names in the PRD, the event names in the warehouse and the states the data actually moves through are three different things, and a dashboard built on the first two reconciles perfectly against the wrong definition.
• cx-running-sheet · Code. Weekly contact-centre insights from Amazon Connect: segments separated from conversations, themes coded from transcripts only, and unique-user figures withheld when identity coverage cannot support them. Written after a single-call pull returned the first 300 rows of a much larger window and nothing looked wrong.
• observability · Code. Real-time business alerting built inside MoEngage. It turns an observability sheet into approved alerts, builds them in the browser, proves delivery, and audits for alerts that silently stopped. Ten skills, eight agents, 23 eval cases, scalable across tenants.
• uk-compliance-knowledge-base · Write-up. Retrieval over the UK retail financial-services rulebook, with page-precise PDF citations and a rule that makes the system decline rather than paraphrase. A confident paraphrase of a rule that does not exist is worse than no answer.
• enterprise-rag-knowledge-base · Write-up. Retrieval question-answering over a company's internal product documentation, built end to end. The lesson I keep: write the eval set before the pipeline, not at phase four.
• amazon-connect-flow-tools · Code. Renders an Amazon Connect contact flow as a draw.io diagram, and repairs and validates an export before you import it. Python stdlib only, 35 tests. Written after a failed import at 11pm before a go-live, caused by one placeholder ARN.
• prd-builder · Code. A product requirement from source ticket through PRD, review, delivery tickets and test design, with a definition-of-ready gate the downstream skills obey. It exists because the expensive failure is not slow writing, it is a document that reads as finished and is not.
• release-notes-plugin · Code. Compiles release notes per tenant (a client, product, BU or OU) from the tracker, a deploy signal and the email or chat threads you point it at. Every line links to the ticket, release or message behind it, and nothing goes out until the owner approves in the session. Each tenant sets its own definition of "released", so a ticket that is only Done, or only mentioned in a thread, is never called shipped. Ten blocking gates, 11 skills, 29 eval cases, 116 harness tests. It exists because the costly release note is not the late one; it is the one that tells a client something shipped when it had not.
• agent-relay · Code. Drives one outcome across several Claude skills, plugins and subagents in a single session. It turns the outcome into criteria a fresh verifier can check, tests whether each named agent actually fits before any work starts, plans steps from what each one reads and writes rather than the order you named them in, and hands off through typed packets that never carry an approval. Read-only steps run as subagents; anything that needs a person, a side effect or its own agents runs in the main thread, and a hook enforces the difference. Eleven blocking gates, seven skills, 32 eval cases, 78 harness tests. It exists because the expensive failure in a multi-agent chain is not a slow handoff; it is the orchestrator saying yes on your behalf.
• job-evaluator · Code. Scores resumes against a job description for a recruiter and recommends Shortlist, Review or Not recommended, with a quoted resume line behind every point and a human confirming every call. The rubric is frozen and hashed before any resume is opened, and the step that scores a person sees only that rubric and one redacted resume. Building the rubric after seeing the candidates is how a screen ends up justifying whoever scored well.
• humanise-plugin · Code. A Claude Code plugin that rewrites AI-shaped prose back into the writer's voice with every fact, number and citation intact, working from a catalogue of 21 named patterns. It exists because the tells are easy to name and hard to see in your own draft.
• profile-optimiser-plugin · Code. The humanise discipline pointed at resumes, LinkedIn profiles and READMEs: two tests per line, no invented numbers, and an output gate so the rewrite does not read as generated.
• spa-automation-toolkit · Code.
• eloquence-etiquette-coach · Code. A Claude plugin that coaches senior people on speaking, writing, presence and business etiquette: on-demand answers, a 60-second brief before a room, rewrites and critiques of pasted emails and transcripts, drills, and one graded lesson emailed every morning. Every answer names the mechanism, the condition where it breaks and a real source, and a six-check gate holds back anything a well-read professional already knows. 160 concept seeds across 8 domains, no repeat within 60 lessons, 21 eval cases. It exists because most communication advice is either obvious or a popular myth, and the useful part is knowing when a technique stops working.
• ats-resume-evaluator · Code. A Claude skill that scores a resume for applicant tracking system readiness: 0 to 100 across 31 checks with fixed thresholds, plus a match rate when a job description is supplied. It extracts the text the way a parser does and quotes what got lost, such as dates that drift away from their roles, skill grids that scramble and a LinkedIn link with no visible URL. The rewrite applies only the recommendations you accept and never invents a number, then re-scores the new file to prove the lift. Three independent runs on the same resume land within a point of each other. It exists because most resume checkers hand back a number without the text behind it, and the expensive mistake is polishing wording the parser was never reading.
• agent-evaluator · Code. Scores agent skills, plugins and MCP servers on 12 weighted dimensions, sandboxed pen-testing among them, with file and line evidence behind every security finding. A single Critical finding fails the verdict whatever the average says. Target code runs only in a network-isolated jail seeded with canary secrets. MCP servers are launched three times to catch a tool list that changes between runs, then fuzzed. The engine never calls a model and never posts: model-dependent dimensions stay not_run rather than guessed, and GitHub drafts wait for approval. Nineteen skills, a 22-attack catalogue and 45 tests. Its self-test catches 42 of 42 planted flaws, and the README says why that number is circular. It exists because an average hides the one finding that matters: a skill can read well and still send your .env somewhere.

LinkedIn: linkedin.com/in/sayandip-bagchi-3a04aa83 · Email: sayandip.bagchi@gmail.com

If something here is useful, missing or wrong, issues and pull requests are welcome. The write-ups especially: if you have built the same thing and reached a different conclusion, I would like to hear it.