Work

What we built, the constraints, and the result.

The numbers behind these engagements are shared in conversation, where we can walk you through the context they came from.

A global footwear & apparel group

Graph data platform for a multi-brand ecommerce operation

Relationships between products, customers, and brand data were trapped across relational systems. Recommendation and prediction work was slow and shallow, and every new question about how entities connect meant another one-off integration.

Constraints

Enterprise master data serving a full portfolio of global brands
Existing warehouse and ingestion landscape, no big-bang replacement
Query performance fit for product-facing use, not just analytics

Stack

Amazon Neptune
Neptune ML
Gremlin
Rust
AWS Lambda
Terraform

What we built

A graph data platform on Amazon Neptune, modeling the relationships the business actually asks about
ML-driven predictions and recommendations with Neptune ML
A full graph search API with a custom query DSL, so product teams query relationships without learning Gremlin
Optimized ingestion pipelines feeding the graph from enterprise master data
Serverless Rust services on AWS, infrastructure as code in Terraform

How AI accelerated it

Agentic coding workflows produced the volume: scaffolding, tests, pipeline plumbing. Senior engineers owned the graph model, the DSL design, and every query-performance decision.

Result

In production, serving the group's full brand portfolio
Graph-backed predictions and recommendations available to product teams through a single search API
New relationship types and query patterns ship without a new integration project each time

What they kept

Full Terraform IaC
Documented graph model and DSL specification
Team runbooks

The same global consumer-brands group

MCP servers: AI-agent access to enterprise master data

The company had unified master data and real appetite for AI, but no safe path between them. AI agents could demo against sample data; nothing could be trusted to query and act on the real enterprise platform.

Constraints

Enterprise data with real commercial sensitivity
Access had to be scoped, auditable, and explainable to stakeholders
Multiple teams and agent surfaces consuming the same interface

Stack

MCP
LLM APIs
Rust
AWS
Amazon Neptune

What we built

MCP servers exposing the enterprise master data platform to AI agents: scoped tools, not raw database access
Integration of LLM-driven workflows into real business processes, not standalone demos
Governance as architecture: logging, access control, and human decision points on actions that matter

How AI accelerated it

Built with the same agentic workflows it enables. Humans owned the tool surface design, the access model, and every governance decision. That is the part that makes it production instead of a pilot.

Result

AI agents across the organization query and act on unified brand data through one governed interface
Stakeholder requirements translate into agent capabilities as roadmap items, not research projects

What they kept

The MCP servers and tool definitions
Access-control model and audit surface
Integration playbook for new agent consumers

The same group, organization-wide

An AI gateway for every team in the organization

AI adoption was happening team by team: separate keys, separate bills, no shared guardrails, and no view of what was being used where. Every experiment started from zero, and most stayed experiments.

Constraints

A full portfolio of brands and teams at very different levels of AI maturity
Central visibility over cost and usage without slowing anyone's work down
Sensitive brand and product data behind almost every use case

Stack

LLM gateway
LLM & image APIs
AWS
Access control
Observability

What we built

An organization-wide AI gateway: one governed entry point for LLM and generative-AI usage across teams
Routing, cost and usage visibility, and per-team access control behind a single interface
Governed experimentation on top of it, including image generation for creative and product workflows

How AI accelerated it

This is the emerging-technology arm of the same engagement. The gateway is what turns scattered AI experiments into a capability the whole organization can use with confidence.

Result

Every team reaches approved models through one gateway instead of private keys and shadow usage
Experiments run inside governance from day one, so the promising ones have a path to production

What they kept

The gateway and its configuration
The access and cost-control model
An experimentation playbook teams run on their own

A European telecommunications provider

High-availability Rust services against legacy telco platforms

Legacy telecommunications platforms were expensive and risky to change directly, but the business needed new capabilities that had to talk to them reliably, at telco expectations of availability.

Constraints

Legacy interfaces that could not be modified, only integrated against
High-availability requirements: telco-grade uptime expectations
Incremental delivery; a big-bang rewrite was off the table

Stack

Rust
Tokio
Kubernetes
CI/CD

What we built

Asynchronous Rust microservices (Tokio) interfacing with the legacy platforms
Kubernetes deployment for high availability and safe rollout
An incremental integration path: new capabilities beside the estate, not a replacement of it

How AI accelerated it

Predates today's agentic tooling. The ownership model is the same one ARSIAR runs now: senior engineers accountable for reliability, decomposition, and every integration decision.

Result

New services in production alongside the legacy estate, meeting availability requirements
Change became routine: deploy a service, not renegotiate a monolith

What they kept

The services and deployment configuration
Integration documentation for the legacy interfaces

Your problem won’t look exactly like these. That’s the point of a technical call.

Book a technical call