Software Systems Engineer Senior Associate

* NOT OPEN TO C2C OR W2 REFERRALS AT THIS TIME*

Position: Software Systems Engineer Senior Associate

Location: Remote

Job Description:

The ISD team runs its delivery work through a shared library of Claude toolkits: pricing engines, deployment pipelines, dashboards, a reference architecture catalog, and an Obsidian knowledge base, all wired to Smartsheet and SharePoint and driven by six named Claude agents.

It works. It is also a 692 MB folder on SharePoint with no version control, where the code, the customer data and the published outputs sit in the same tree, and where every routine task loads a large part of the library into a Claude session before it does anything. Four people can drive it. The rest of the team cannot.

We need someone to own that platform and make it usable by the whole team, not just the people who can read the code. Four jobs.

Keep it running and extend it. SharePoint and Smartsheet integrations, the dashboards and reports the team publishes, the shared Python library underneath. This is the standing half of the role and it does not stop while the rest happens.

Take the toolkits off the context window. Every toolkit today is markdown instructions and Python that a Claude session reads before it does any work, so a routine pricing run or a data refresh costs tokens in proportion to the size of the library rather than the size of the job. The work is to measure where the tokens actually go, then move the routine paths behind a callable surface so the model invokes a typed tool instead of reading the library.

An MCP server, a packaged plugin with progressive disclosure, a headless Agent SDK service, and a small internal web app are all on the table. We have not picked one, and a candidate who arrives having picked one without measuring is answering a question we have not asked. The target is a stated reduction in cost and time per run against a baseline you establish in the first month.

Run it in Git Hub, with the data kept out. The library has no version control today. Own the migration, the CI, and packaged releases of the skills and agents. The harder half is the boundary: the code goes to Git Hub, and the customer pricing data, the deal content, the knowledge base and the published outputs stay in systems and never reach a repo.

You design that split, set up the scanning that enforces it, and solve distribution, because a consumer on a fresh Mac has to be able to install a release and point it at SharePoint data without asking an engineer.

Open the knowledge base to the team. The ISD Brain is 926 wiki pages built from 875 source documents and 377 meeting summaries, with citation rules, source confidence tiers and restricted pages that must not leave the vault. One person ingests into it today and one person queries it well. The job is to make it a retrieval surface the whole team uses and contributes to, which means multi-user writes on a SharePoint-synced vault, access control that holds for restricted pages, grounded answers that cite the page they came from, and a system that says "I don't know" instead of filling the gap.

This is hands-on build work. The deliverable is working code and documentation someone can follow without asking.

Toolkits- 9 registered toolkits plus a shared _platform library, ~200 Python files, ~62,000 lines, 33 skills, 6 named agents

Version control
- None today. A 692 MB SharePoint folder synced to each person's Mac

Knowledge base- ISD Brain, an Obsidian vault of 926 markdown pages, 875 raw sources, 377 meeting summaries, 836 MB

Systems of record
- Smartsheet for REQ tracking, price sheets and the backlog;
SharePoint for the library and published outputs

Access model
- Four roles already defined: owner, maintainer,…