Work project · In production
Agentic Compass
Understand. Route. Build. Prove.
A human-supervised, understand-first AI agent for GitHub Copilot: give it a Jira ticket and it returns business context, evidence-backed analysis, a routed implementation plan, real test verification and an auditable history, with every remote write approved by a human. I built it in about a week in my current role as a Senior Software Engineer at MAS Global Consulting (client: JPMorganChase, Offers team), and after senior engineering lead reviews and UAT it is in production.
Professional work. Internal names, tickets and service details are left out on purpose; results are described generically.
Problem
Engineers kept paying the same discovery cost before writing any code: reading the ticket, finding predecessor work and pull requests, choosing the right base branch, setting up runtimes, and working out which tests actually prove the acceptance criteria.
Generic "Jira-to-code" agents skip that work. They jump straight to code, miss hidden dependencies and say the code "should pass" without running anything. Meanwhile the organization already had many specialist AI skills (security remediation, testing, API governance, infrastructure) but no front door to pick the right one and no shared format for evidence.
Approach: the router pivot
I started out building another Jira-to-code agent. Then I realized capable specialist skills already existed. What was missing was understanding, routing and evidence.
So I turned Agentic Compass into an orchestrator: it understands the ticket first, then deterministically routes the domain work to the existing specialist skills instead of duplicating them. The strictest child-skill guardrail always wins, and the router never inherits the union of its children's permissions.
Review mode asks zero routine questions. The only mandatory human decision before coding is the base branch, and every claim is labeled VERIFIED, INFERRED or UNKNOWN with file:line or source citations.
The missing pieces were understanding, routing and evidence.
Architecture
- inputJira key
- askBusiness brief + acceptance criteria
- analysisRepo fit, history, overlapping PRs, blockers
- routeDeterministic route to specialist skills
- human"go" + verified base branch
- implementLocal changes only
- testsEach layer: what it proves and doesn't
- historyAppend-only event log
- humanConfirmed push / PR / evidence
Human decision: nothing happens past these steps without the engineer.
Small and dependency-free. Python 3.11+ standard library only, plus plain JavaScript, HTML and CSS with no framework or build step: about 5,000 lines across 7 single-responsibility modules (routing, skill resolution, a Jira fallback, repository preflight, workspaces, gated state, dashboard).
A resumable workspace per ticket, Git-excluded so it never pollutes a pull request: a summary, command proof records, versioned state, the event log, raw artifacts and Bruno API checks.
19 routes cover security findings, dependency and container vulnerabilities, component, contract and performance testing, feature work, API governance, infrastructure-as-code and an explicit "unknown" route. All 61 referenced specialist skills resolved.
A read-only dashboard with five tabs (Ask, Analysis, Implementation, Tests, History) plus Commands, bound to loopback, with secret redaction and scoped per repository.
Guardrails & governance
- A human approves every remote write. Push, pull request and evidence are each previewed and confirmed; no command implies the next.
- It never deploys, merges, changes traffic, flips feature flags, transitions Jira tickets or changes cloud resources.
- Least privilege. The strictest child-skill guardrail wins; the router never inherits the union of child permissions.
- Evidence labels. VERIFIED / INFERRED / UNKNOWN, with file:line or source citations.
- Audit trail. An append-only event log, plus proof records of each exact command, working directory, exit status and what it proves.
- Secure by default. Loopback-only, read-only dashboard with redaction; zero dependencies; Git-excluded workspaces.
- The scanner decides. For security findings, the original scanner is the oracle for closure.
- Formal process. Senior engineering lead reviews → UAT → production, for the tool and for the code changes delivered through it.
Results
Validated on 8 real tickets across 5 services before production rollout. Across them, the most useful output was often a reason to stop: it surfaced wrong ticket assumptions, overlapping pull requests, diverged branches, cosmetic security fixes and missing dependencies before coding, instead of guessing.
- Java/Maven service · A/B test featureA change delivered through Agentic Compass implemented a feature-flagged A/B test feature: 357/357 unit and 24/24 component tests passing, 100% coverage of new lines and branches (JaCoCo). Flagged an unstarted dependency ticket and an unspecified flag name.
- Same service · compliance findingShowed the prescribed security fix would only change scanner detection, not remove the underlying exposure; escalated to the owners instead of shipping a cosmetic fix.
- Java API service · cleanupFound an open overlapping PR and a diverged release branch, and blocked delivery until the dependency merged. A change delivered through Agentic Compass then touched 14 files, with 87.2% module line coverage, 100% changed-line coverage.
- Same service · CI test reportingStayed analysis-only because required details were missing and the linked guide was inaccessible, rather than guessing.
- Python AWS Lambda service · SAST findingIdentified candidate sinks with file:line evidence; a change delivered through Agentic Compass put the fix on a feature branch, with the scanner re-scan as the closure oracle.
- Same service · SDK upgradeFound the ticket's assumption about SDK usage was wrong, found an unmerged prior upgrade, and flagged a 250 MB package-size risk.
- Java service · component testsFound test-data and assertion gaps in a story already marked "Ready for Review".
- Container-image findingShowed closure depended on the deployed image and pipeline, not the repository's code.
Tech stack
- Agent
- GitHub Copilot agent skills, MCP (Jira) with a bounded-retry CLI fallback, specialist skill routing
- Code
- Python 3.11+ standard library, plain JavaScript / HTML / CSS, no dependencies
- Verification
- Maven, JaCoCo, Bruno (API checks), component, contract, coverage and performance test layers
- Quality
- 73 unit tests; two-layer evals (skill-selection prompts, routing fixtures)
What I learned
- Check what already exists before building. The biggest design win was not writing another code generator: the specialist skills existed, and the gap was understanding, routing and evidence.
- Stopping is a feature. On real tickets, the most valuable result was often a reason not to code yet: a wrong assumption, an overlapping PR, a fix that would only have been cosmetic.
- Say what a test doesn't prove. Recording what each test layer proves, and what it doesn't, keeps unit, local, deployed and production evidence from being confused.
- Small is a safety property. Standard-library code with no dependencies means no dependency-scanning overhead and a small attack surface; a loopback-only, read-only dashboard and human-approved writes keep the risky actions with people.
What's next
- Wider adoption.
- Contributing it upstream as an optional plugin.