Start small, with evidence
Each offer begins with a short, fixed engagement. You see the architecture and the evidence before you commit to a build, and if the evidence says stop, we say stop.
Design sprint, 4 to 6 weeks
- Week 1: the KPI baseline, agreed with operations and taken from your historical situations.
- Weeks 2 to 4: design workshops across vendor, operator and platform teams; target architecture; an open-question register with owners.
- Weeks 5 to 6: a go or no-go for an MVP with one use case, its production path and its run cost.
- You leave with a solution description, the KPI baseline and the register.
Assessment, 2 to 3 weeks
- A Well-Architected or landing-zone assessment built on evidence from your estate, not interviews alone.
- Every finding points at a resource someone can fix, in a remediation backlog with owners.
- A plan for what comes next: enablement for your team, or a build with ours.
- Add an enablement programme when your team has to run the platform afterwards.
Architecture review, 3 to 4 weeks
- Runtime design: how the agent executes, which tools it may call, how actions are confirmed.
- The evaluation harness, the tracing, and the model routing, designed before any build.
- Residency, GDPR and EU AI Act requirements mapped to the design, line by line.
- Or a build: one bounded agent in 6 to 8 weeks, with its evaluation harness, in your tenancy.
What follows is delivery with a small senior bench of Kubernetes and AI engineers. We run two or three engagements at a time, through vendor and MSP partners or directly. When a programme needs an owner rather than a team, we take it on at advisory CTO level; one platform went from red to stable that way.
The working session
Before any of this, most conversations start with a 45-minute working session. It is a private walkthrough of a build that is close to your problem: the agentic NOC, a landing zone, an agent runtime. We show the real architecture and the real numbers and take your questions. No slides and no proposal.
Bring the problem you are trying to solve and the people who would own it. You leave with a view of what it would take, what we would check first, and whether we are the right people for it. If we are not, we say so.
How we architect
- Non-functional requirements first. Latency, cost per unit, data residency and auditability are decided before the happy path is drawn.
- Deterministic over emergent wherever an operator must audit the outcome. An agent that cannot reproduce its output does not go near production.
- Failure modes named before the happy path. What happens when the model is wrong, slow or unavailable is designed, not discovered.
- Reference architectures mapped to industry levels, such as TM Forum Autonomous Networks, so a roadmap has a shared vocabulary.
- Build enough to know. We are hands-on in LangGraph, MCP, A2A, LiteLLM and vLLM, Kubernetes, Terraform and Bicep, far enough that the plan is real.
Who you work with
Kartik Sama leads every engagement, either as hands-on lead architect or as engagement lead over an Atsky team. He has 25 years in enterprise systems, 22 of them with telecom operators and vendors, and he writes the solution description that vendor, operator and ISV all sign.
The bench is small and senior: Kubernetes and AI engineers who have shipped platforms and agents into production. We are based in Amsterdam and Miami, deliver on site in the EU, and are work-authorised in the EU and the United States.
What we do not do
- We do not deliver strategy on slides and leave the hard parts to someone else.
- We do not run open-loop agents on production networks. The agent recommends, the operator decides.
- We do not start a build before the KPI baseline is agreed with the people who will measure it.
- We do not name clients who have not agreed to be named.