We tell our customers that AI agents can replace entire workflows. That a single platform can do what used to require a team of people and a stack of tools.
If we believe that, we should prove it ourselves first.
Eating Our Own Dog Food
Salesteq is built on 48 microservices communicating via gRPC, message queues, and HTTP APIs. Making changes that span multiple services is one of the hardest problems in software engineering: you need to understand the full service map, respect every contract, sequence changes to avoid breaking dependencies, and somehow parallelize work that's almost always done sequentially.
This is exactly the kind of work AI agents are built for. So we built an AI Agent Orchestrator that does it.
Not as a product to sell. As the way we actually build Salesteq.
The Architecture
The system has three layers.
The Architect Agent receives a high-level task - "Add a user notification preference service with gRPC and Kafka integration" - and produces a structured execution plan. It has full access to our services map, every gRPC proto contract, every queue message schema, and the business context of each service. It knows what talks to what, and why.
The output is a JSON array of steps: which service to modify, what action to take, what the task description is, and which steps depend on which. Steps without mutual dependencies are automatically flagged for parallel execution.
The State Machine manages the lifecycle of every session and step. It tracks state transitions (PENDING → IN_PROGRESS → COMPLETED or FAILED), resolves dependencies before dispatching work, detects failures, halts dependent steps, and provides real-time visibility into what's happening across the entire execution.
The Agent Pool is a collection of AI coding agents - each one picks up a step, loads the target service codebase and its contracts, implements the required changes within that service boundary, reports back, then picks up the next available step. One agent, one service at a time. Clean isolation. Full utilization.
How It Runs in Practice
A real execution looks like this:
- An engineer submits a task: "Add user notification preferences with gRPC and Kafka integration."
- The Architect Agent analyzes the services map and produces a plan with 6 steps across 4 services.
- The State Machine identifies that steps 1, 2, and 3 have no mutual dependencies - they can run in parallel.
- Three agents pick up those steps simultaneously. Each loads its target service and begins work.
- Steps 1 and 2 complete. The agents report back and immediately pick up steps 4 and 5, which depended on step 1.
- Step 3 completes. That agent picks up step 6 - the final integration step, which depends on 4 and 5.
- All steps complete. Session done. Summary report generated.
Six steps across four services. Three of them running in parallel. The Architect understood the dependency graph. The State Machine enforced it. The agents executed it. No engineer had to context-switch between services, manually sequence changes, or worry about breaking contracts.
Why This Matters
This isn't about replacing engineers. Our lead engineer designed this system. Engineers define the tasks, review the output, and make the architectural decisions. What changes is the execution layer - the tedious, error-prone, cognitively expensive part of cross-service development.
The principles are the same ones we apply to our customers' commercial operations:
Parallel execution. Independent work runs simultaneously across multiple agents. Total execution time drops dramatically.
Contract awareness. Full visibility into gRPC protos and queue message schemas. Changes respect existing contracts and dependencies.
Service isolation. Each agent operates within a single service boundary. No unintended side effects across services.
Scalable pool. Need more throughput? Add more agents. They're stateless and reusable.
Failure resilience. Every step is tracked. Failures are detected, dependent steps are paused, retries are triggered.
The Principle Behind the Practice
We started Salesteq with a conviction: the next generation of companies will be AI-native from the ground up. Not "AI-assisted." Not "AI-enhanced." AI-native - where autonomous agents are the default way work gets done, and humans focus on judgment, creativity, and decisions.
That conviction has to start with us. If we can't use AI agents to build our own platform, we have no business telling others to use them for their commercial operations.
So we do. The Architect Agent plans. The Agent Pool executes. The State Machine orchestrates. Our engineers design, review, and decide.
That's what AI-native means. Not talking about AI. Being about it.