Agents
Agents scoped to the actions you name, for the roles you name.
- Tool allow-lists per role
- Retrieval with access control applied before the search, not filtered afterwards
- Writes drafted as proposals; the agent itself never saves them
AI agents that can take real actions, safely.
The first time an agent writes (updates a record, sends a message, moves money) is when a demo becomes a production problem. We build agents that handle that moment: permissions scoped to the actions you name, a person approving every write, and evals that tell you whether it still works.
What we build
Four parts of the same job: the agent, the evals, the guardrails, and the work that gets it in front of real users. Each list below is what our demo does, and what we scope for yours.
Evals
A golden set of cases you can read and re-run, delivered with the build.
- Cases that must answer with a citation
- Cases that must refuse
- Cases where one role must not see another role's content
Guardrails
Limits on what the agent can do without a person. The demo does these; we scope them for yours.
- Human approval before any write: creating a record, sending a message, moving money
- Refusal when there is no grounded answer, instead of a guess
- A step limit on the agent loop
- Logging of AI calls, with sensitive content redacted
Production hardening
The work between “it runs on a laptop” and “real users touch it”. The demo shows some of it; we scope what your engagement needs.
- Deployment to your own infrastructure
- A fallback when the model provider errors or is over quota
- Rate limits on requests
- Production readiness assessment, then handover with a runbook
The current offer
We sell agent work through the engagements on our services page, not as a separate package. Agent work is scoped on a call, against the In-App AI Assistant Pilot: an assistant embedded in your product, grounded in your data, with guardrails, an evaluation harness and a production readiness assessment.
If you are not sure an agent is the right shape, start with the AI Readiness Audit: a written report on where AI genuinely helps you, where it is hype, and what to do first. When the work is bigger than one specialist, Beyond a Sprint covers it, with a team assembled for the engagement.
Two engagements behind this work
Internal Knowledge Assistant, shown by the Policy Assistant
Role-based access enforced at retrieval time, and human approval before a ticket is created. Sign in as an Employee, a Supervisor or an Admin (three roles) and ask the same question. It runs over sample policies for a fictional company.
policy.compcodesolutions.com · The Internal Knowledge Assistant engagement
Web Regression Safety Net
For an agent or assistant that ships inside a web app: we explore the app automatically, capture an approved baseline of how it looks and behaves, and check each release against it. You get a report showing exactly what changed.
Proof you can open
- Live demo: policy.compcodesolutions.com, with three roles: Employee, Supervisor, Admin. An Employee cannot reach Supervisor-only content, and a ticket is only created after a Supervisor or Admin approves it.
- Public source: github.com/compcode-solutions/contoso-policy-assistant, a reference implementation with tests and architecture decisions.
- Passing tests: the unit tests and the golden evals run in the repository’s CI on every push.
- 14 golden eval cases: answer, refuse and leak cases. The demo page has a “Run the safety tests” button that runs all 14 and shows each result.
- Write-up: why filtering RAG results after retrieval leaks data.
Technical delivery is led by Amit Ranjan, Technical Architect, CompCode Solutions, who has 17 years of enterprise software behind him. We do not publish client names or outcome numbers here. Everything on this list is something you can open and check yourself.
How an engagement runs
-
Discovery
A 25-minute call about the workflow you want an agent to run, and what must never happen without a person. If we can help we will say exactly how; if we cannot, we will say that too.
-
Scoped build
A two-page scope within 24 hours: deliverables, timeline, and an explicit list of what is not included. Then working software throughout, with a weekly check-in.
-
Evals
An evaluation harness is part of the build, so you can measure whether the answers are good: the answer, refuse and who-can-see-what cases for your roles.
-
Handover
A session, a runbook, and everything in your repositories. You own all of it.
Questions
Which models?
The public demo runs on Gemini. OpenAI and Azure OpenAI are supported behind the same interfaces. We choose the model with you for your engagement.
Can it run on our infrastructure?
Yes. Everything can be deployed to your own infrastructure.
How do you test it?
With a golden set of cases, including the ones that must refuse and the ones where one role must not see another role's content. The public demo has 14, and you can run them from the demo page.
What needs a person?
Anything that writes: creating a record, sending a message, moving money. In the demo, a ticket is only created after a Supervisor or Admin approves it.
Who owns the code?
You do. Everything transfers on final payment. We retain rights only to general tooling that predates the engagement.
Worth a conversation?
25 minutes. Tell us the workflow you want an agent to run, and what it must never do without a person. If it is not a fit, we will say so and point you somewhere useful.