Example engagements
Agent delivery, shown rather than described.
Two kinds of evidence live here. Open source agents are working implementations of the patterns we deliver, published in full so you can read the tool boundaries before you talk to us. Case studies are client engagements, published once they have shipped and the client has approved the write up.
The projects
MODERNIZE
Java Modernization Agent
A self hosted agent that assesses a Java estate, applies version pinned OpenRewrite recipes on a branch, verifies the build on Java 21, and waits for your architect before anything is pushed.
INVESTIGATE
Incident Investigator
A local model investigates real failing requests across two Java services through five read only MCP tools, and every claim in its assessment cites evidence you can open.
COLLECT
Splunk Remote Log Agent
A central collector that reads Java and Linux logs over verified SSH, redacts before storing, and delivers to Splunk HEC through a durable queue with at least once delivery.
Modernize
MNM Java Modernization Agent
A self hosted AI assistant that helps a team move a Java application to Java 21 and a current Spring Boot. It reads the code, reports what will break, applies tested and version pinned OpenRewrite fixes on a separate branch, reruns the build and tests, and hands your architect a review package to accept or reject. It never merges, never deploys, and never sends anything outside your network.
The situation
Automated tooling handles a large share of a mechanical Java upgrade and then stops at the parts that need judgment: the dependency with no Jakarta artifact, the module with no tests, the security configuration that has to be reasoned about. Teams want an agent to carry the mechanical share without handing a model the ability to push to main, read secrets, or declare the application ready.
What is built
- A six step run: inspect the repository, baseline the build and tests as they are today, assess blockers and plan, change on a branch named
mnm/*using allowlisted OpenRewrite recipes with one commit per recipe, verify on Java 21, and produce a review package. - Two stops for a person: after the assessment, to approve the plan, and before any push. An approval is valid for one operation only, a plan approval cannot be reused for a push, and a rejection is recorded in the same ledger.
- Deliverables the team keeps: the assessment with every blocker at file and line, the branch, a review package with test results before and after (pre existing failures kept separate from new ones), unresolved risks, rollback steps, and an audit log with secrets redacted.
How it stays governed
- Three tool tiers, enforced by tool servers rather than by the prompt: read tools inspect, build, test, and dry run; write tools apply recipes and commit only on
mnm/*branches; the privileged push tool refuses to run until a person records an approval id. - Rules the model cannot change: policy lives in
config/policy.yaml. Force push, hard reset, branch deletion, merge, and deploy are not tools at all. - Repository text is data: if a README or a comment tells the agent to do something, the agent reports it and does not obey it.
- Nothing leaves: inference runs on your GPU with a locally served
Qwen3-Codermodel, builds run offline, and source, logs, and model traffic stay on your hardware. The same deployment posture is described on the how it works page.
Status and limits
This is a pilot design and reference implementation. It has not yet been run against a client repository. The pilot scope is one repository and one target, and it is accepted only when agreed checks pass, behavior is preserved, blockers are found accurately, and a change is accepted within the agreed time. Every review package is marked needs-review, and the tools are built so that they can never write the words production ready.
Technologies
Python, Goose agent runtime, MCP tool servers, OpenRewrite, Java 21, Spring Boot 3.x, Maven and Gradle builds, a locally served Qwen3 Coder model, Docker Compose, approval and audit ledgers
Investigate
MNM Incident Investigator
Ask why orders are failing. Watch a local model gather evidence through read only tools. Check its explanation against the actual requests. The showcase runs two real Java services, introduces one controlled failure, and gives the model five telemetry tools. The model chooses its own queries and writes an assessment with resolvable evidence links, qualitative confidence, and explicit uncertainty.
The situation
An incident explanation from a model is only useful when an engineer can verify it. A confident narrative with nothing behind it is worse than no answer in the middle of an incident. The question this project answers is whether an agent can be given real telemetry, choose its own queries, and produce an assessment in which every claim resolves to a record you can open.
What is built
- Two real Java 21 and Spring Boot services, orders and inventory, with actual HTTP traffic, structured JSON logs, and parent and child spans connected by W3C trace ids. A protected local control introduces one fault: an inventory delay that exceeds the orders request timeout.
- A read only MCP service with five tools:
get_service_health,get_service_map,query_metrics,search_logs, andget_trace, with strict filters and persistent evidence snapshots. - A local investigation agent: a bounded tool calling loop over Ollama, with
qwen3:8bas the default model. No shell, no write tools, and no cloud inference fallback. - A browser console: measured health and traffic, operator controls, the investigation timeline, an evidence viewer, and equivalent recovery windows for before and after comparison. No frontend framework and no external dashboard.
What it shows
The investigator receives no fault state, control token, or scenario description. It has to establish the downstream delay and the orders timeout from telemetry alone, and those observations cannot explain why inventory became slow. A useful assessment names that uncertainty and asks for the observation needed to resolve it. Deterministic code retrieves records, calculates statistics, enforces budgets and permissions, and validates citations and evidence sufficiency. Invalid, missing, or insufficient evidence produces an incomplete result rather than a replacement story. A live evaluator checks actual model output and citation checksums, and its expected result is never sent to the model.
Limits
One local, synthetic scenario. Telemetry can be dropped when its receiver or bounded export queue is unavailable, and there is no production authentication, alerting, or high availability. The deterministic tests prove controller behavior, not live model quality, and model judgments require an engineer's review.
Technologies
Java 21, Spring Boot, Python, SQLite, MCP, Ollama, Qwen3, W3C trace context, a documented JSON telemetry protocol, Docker Compose, Maven, GitHub Actions
Collect
MNM Splunk Remote Log Agent
A central Python collector that reads configured Linux log files over verified SSH and SFTP and forwards redacted events to the Splunk HTTP Event Collector over verified HTTPS. Remote servers need existing SSH access and readable files. They do not need a collector installed.
The situation
An investigation agent is only as good as the telemetry it can query, and the servers that matter most are often the ones nobody is allowed to install anything on. Getting Java, Tomcat, and system logs off those hosts reliably, with secrets redacted before anything is stored, is unglamorous plumbing that has to be right.
What is built
- Collection: AsyncSSH file reads with explicit allowed paths, resolved symlink checks, bounded host concurrency, intervals, and bandwidth limits, covering Java, Spring Boot, and Tomcat text, web access and error logs, readable Linux system files, and newline delimited JSON including exported container logs.
- Recovery: persistent checkpoints, append only reads, partial line recovery, Java multiline grouping, conservative rotation and truncation detection, reconnects, and restart recovery.
- Redaction and identity: configurable redaction before durable storage, event ids that stay stable across delivery retries, source timestamps when parseable, and collection, source, service, environment, and severity metadata.
- Delivery: a SQLite transactional queue with separate collection and delivery state, queue saturation backpressure, HEC batching, bounded requests, retry backoff, and optional indexer acknowledgment.
- Operations: a CLI that validates configuration, tests the SSH and HEC connections, runs, and reports status. The HEC token comes from a named environment variable through your secret manager, never from the configuration file.
Validation and limits
The complete automated suite passed 98 tests, including real localhost SSH and SFTP and verified HTTPS, with CI configured for Python 3.11 to 3.13 and the Compose scenario. The reproducible demonstration runs three simulated SSH servers through normal ingestion, independent host failure, receiver outage, collector restart, recovery, and rotation. The demo uses a HEC test receiver rather than Splunk, and live Splunk checks have not run. The file adapter is implemented; journald and container API adapters are planned interfaces only. Delivery is at least once, so duplicates are possible, and HEC acceptance is distinct from confirmed indexing.
Technologies
Python 3.11 and newer, AsyncSSH, SQLite, Splunk HEC over HTTPS, TOML configuration, Docker Compose, pytest, GitHub Actions
Case studies
Client engagements, published with the client's approval.
Current engagements are listed here as in progress, without naming the client until the client agrees to be named. Outcomes are added only after the work has shipped and the client has approved the write up, because a case study you cannot check is worth less than a repository you can. The open source agents remain the evidence you can read today.
Life sciences
Machine learning inference platform for assay and imaging workflows
A technology consulting firm engaged MNM Technology to continue building a machine learning inference platform for molecular assay and confocal imaging workflows: a Java and Spring Boot service layer on AWS that serves PyTorch and scikit-learn models behind low latency REST prediction endpoints used by scientific analysis and decision workflows. The principal architected the original platform, so the engagement starts from working knowledge of the estate rather than from discovery.
The situation
Models trained in Python for assay and imaging analysis have to reach scientists as reliable predictions inside the workflows they already use. The platform must accept heterogeneous biological datasets, reject malformed inputs at the boundary with structured errors, hold response times flat under peak load, and release model updates the same day without breaking the Java service layer that downstream applications depend on. The seam between Java business logic and Python models is where this kind of platform usually fails, and it is the seam this engagement owns.
What we are doing
- Service layer: the Java and Spring Boot services on AWS (ECS, RDS, S3) that integrate trained PyTorch and scikit-learn models behind REST prediction endpoints, with model packaging and backend integration handled as one release unit.
- Throughput and routing: request batching, asynchronous handling, and multi worker execution in the Java services, and the inter service communication and request routing across the deployment stack using Amazon SQS and ElastiCache.
- Preprocessing pipelines: Java and Apache Spark pipelines on Amazon EMR for standardization, missing value handling, feature alignment, and input consistency checks across heterogeneous datasets, producing model ready feature matrices and removing feature mismatch errors at inference time.
- Validation at the boundary: schema enforcement in Java with Bean Validation and JSON Schema at ingestion, so bad data is rejected early with structured error reporting rather than surfacing as failures downstream.
- Feature workflows and data movement: biomarker prediction workflows that combine experimental measurements with metadata, and the movement of data between S3 storage, preprocessing, feature generation, and model serving for diverse imaging inputs.
- Delivery pipeline: CI/CD for the ML services with Jenkins, Docker, and Amazon ECR through to ECS, with CloudWatch monitoring, so inference updates can be released into live environments repeatably.
- Translation: working with stakeholders to turn biological and experimental criteria into deployable workflows.
How it is delivered
Principal led, corp to corp. Bounded workstreams are executed by agents grounded in a context layer over the platform's repositories, and the principal owns architecture, security judgment, code review, and production readiness, as described on the how it works page.
Outcome
In progress. Results are published here once the work has shipped and the client has approved the write up.
Technologies
Java, Spring Boot, Python, PyTorch, scikit-learn, Apache Spark, Amazon EMR, ECS, RDS, S3, SQS, ElastiCache, ECR, CloudWatch, Jenkins, Docker, Bean Validation, JSON Schema
Next step
Bring us your Java workstream
Each project on this page is the shape of work we deliver: governed agents, deterministic tools, and evidence a reviewer can check. Tell us what has to move and we will say which pattern fits and where an assessment should start.