Agentic engineering is not a solved problem.
No organisation has a fixed multi-year playbook for it, because the space is moving too quickly for that kind of certainty. Every engineering organisation is learning in parallel: experimenting, absorbing new model capabilities, discovering where agents are genuinely useful, and adjusting its approach as the tooling matures.
That is how we are approaching it at Carousell as well. We are not treating agentic engineering as a grand transformation program with every milestone known upfront. We are treating it as an evolving engineering process: investing in the durable foundations, testing against real use cases, and expanding the scope only when the outcomes justify it.
One of the clearest lessons from that journey came from an app crash detection and resolution agent. The idea was straightforward: When a crash surfaced, the agent would inspect the signal, reason about likely causes, and help move the issue toward a fix.
The first versions were hit and miss.
They could read stack traces. They could inspect the code. They could identify suspicious changes. But they often lacked the product context needed to understand what the user was actually doing before the crash happened. Without that context, the agent could still produce a plausible answer, but plausibility was not enough. Engineers needed recommendations grounded in the same operational and product understanding they would use themselves.
The turning point was not a larger model or a more elaborate prompt. It was context.
Once the agent could see the relevant product flow and user navigation events, its reasoning changed. A crash was no longer just an exception in a file. It became a failure happening at a specific point in a user journey, after a specific sequence of actions, inside a system with known service boundaries and ownership.
Accuracy improved. Resolution quality improved. More importantly, engineers could trust the agent’s output because it was no longer reasoning from code alone.
That lesson, and lessons from similar explorations, now shape how we think about agentic engineering.
The Common Tech Foundation is the standardised platform that gives Carousell Group one consistent way to build services across our marketplace businesses, including Carousell, Cho Tot, Mudah, and Laku6. It replaced each business unit’s separately evolved tech stack with one codebase pattern, one build path, one deployment pipeline, and shared conventions across multiple business units. That standardisation was valuable on its own. But it also created the conditions for further work.
When services follow the same architecture, expose contracts consistently, and store configuration in predictable ways, an AI agent can reason about engineering work with greater confidence. Consistency is not just nice for humans reading code. It is what makes agent-assisted engineering tractable instead of becoming a pile of special cases.
That is the frame for how we think about this work: Agentic engineering is not mainly about giving a model access to code. It is about giving agents the right context, safe access to the right tools, and clear human checkpoints around decisions that matter.
The principles we’re holding to
Agentic engineering is not a solved problem. We’re explicit about that internally, because it changes how you invest. You don’t bet the org on a grand five-year vision for something that’s moving this fast. Instead:
Invest wisely, but scope aggressively against real outcomes. We are building the parts we’re confident are durable: internal context, a tool gateway, and a safe runtime. We deliberately widen what we trust agents to do only as fast as real results justify. Each expansion of scope is earned by a shipped outcome, not by a roadmap slide.
The human-in-the-loop approach is a design constraint. Every agent workflow we run has explicit gates where a human approves, rejects, or amends before the agent proceeds. This isn’t a lack of ambition; it’s how you move fast without shipping confident nonsense. Determinism and clear checkpoints now are also what make these workflows safe to run remotely and unattended later.
Internal context (static and dynamic) is the primary enabler. This is the belief the platform is built around. Static context is the slow-moving knowledge: what a domain is, how an order flows, and which service owns which entity. Dynamic context is the live truth: a service’s real call graph, current metrics, and an API trace from five minutes ago. Get both to the agent reliably, and everything else becomes an engineering problem rather than a research one.
The architecture, at a glance
Here’s the shape of the platform. Four layers, each with a clear job, with observability built in.
Interfaces: kept agnostic. Engineers reach agents wherever they already are: Slack, a chat/web UI, or a direct API. No new destination to learn.
Agents: flexible by design. We don’t mandate one framework. Teams start simple with visual, low-code flows and graduate to code-first frameworks as a use case demands more control. Routing agents, use-case agents, and coding agents all live here.
Control and context plane. The load-bearing layer. An MCP Gateway is the single entry point to the tools. eng-agentic-context is the shared, versioned source of static domain knowledge. Authentication, authorisation, observability, and LLM budgeting are enforced centrally.
Foundation (the “Common Tech Foundation”). Standardised services, API/proto contracts, unified config and secrets, and one deployment pipeline. The consistency that makes the layers above possible.
We’re keeping the description light on purpose. The point of the picture is the ordering: Nothing above works without the layer below it, and the two layers we invested in first, the foundation and the context/control plane, are the ones you can’t shortcut.
Inside the platform
Here’s how each layer works in practice, walking up the stack.
Structured context for agents
We’ve invested in a domain context architecture that models our product as a directed graph of domains, subdomains, entities, and use cases. A lightweight graph.yaml manifest gives an agent the topology in one read. It then selectively reads only the subdomain files it needs.
Each service repo has a CLAUDE.md/Agents.md with a domain context section that declares its subdomain, cross-service relationships, and pointers to deeper context. This is the glue between the central knowledge graph and the individual codebase.
MCP Gateway, guardrails, and observability
The MCP (Model Context Protocol) server acts as a single entry point for agents to access queryable internal and external tools via servers exposing the service catalogue, API catalogue, domain and service knowledge, and other resources. Agents use these to look up service definitions, trace call paths, and verify RPC contracts, all without hardcoding assumptions about our architecture, while redacting personal data and enforcing observability.
The agent pipeline
Agentic Runtime: The infrastructure to build and deploy agents safely. Teams can pick n8n, LangGraph/LangChain, or ADK; guardrails on internet exposure, resource access, and AI spend are built in. The runtime also includes devbox, the isolated sandbox that lets an agent run code.
The Dev Agent: Our first use case is an agent that takes a feature request through spec, architecture, planning, and build behind human gates. It covers the flow, the rationale for each action, and the MCP tools around our group infrastructure that make it work. At the core, the pipeline mirrors an engineer’s workflow, with each stage consuming progressively more specific context:
If there’s a single thread through the whole pipeline, it’s the relationship between context and outcomes: Every feature we ship makes the context richer, and richer context can improve the next feature’s agent. The foundation was step one. This builds on it.
