Explain a system to the person beside you with a drawing in 30–60 seconds. That was Murali Suriar's opening exercise at Cursor Compile London on 16 September 2026.
It puts the other person at the centre of the drawing. Which details do they need? What are you assuming they already know? Murali used his home network and Cursor's services to show how a team can build that understanding together.
Cursor Compile London Series
- Pauline Brunet: AI Deployments at Scale
- David Gomes: Git Worktrees for Agents
- Murali Suriar: Diagrams and Shared Understandingyou are here
- Pablo Santos Luaces: How File Merges Work
- Tomas Reimers: Code Review in the Agent Era
- Jet Semrick: Grok Bot Workshop
Three Views of the Same Network
Murali drew his home network three ways:
| View | What it shows | Example question |
|---|---|---|
| Physical | Switches, access points, NAS, desktop, and connections | Why is reading photos from the NAS slow? |
| Subnets and trust | Trusted devices separated from untrusted IoT devices | Which devices should be able to reach each other? |
| Abstract | A network cloud with devices attached | Where should troubleshooting a streaming problem begin? |
The most detailed view is not always the most useful. Choose the drawing for the question, then add detail where needed.
The Cursor Request Path
He drew a simplified route from a laptop to Cursor's services from memory. This records the session sketch, not a current infrastructure inventory.
DNS resolution finds the service address. The application request then reaches a load balancer, which routes to internal services. The sketch included authentication, marketplace, and agent services, databases, an inference proxy, and external model providers.
The responsibilities were explained in one sentence each:
- Load balancer: TLS termination and host/path routing.
- Auth: authentication and authorisation.
- Agent service: manage the harness and send work towards inference.
- Inference proxy: route model requests and stream responses, with billing and routing logic.
- Databases: persist application data; several were collapsed into one symbol.
DNS resolution and the subsequent application request are different steps, even when they appear in the same drawing.
Stable Responsibilities, Changing Implementations
The on-call expectation was to understand the approximate graph and each component's job. Individual routing rules and implementation details could be looked up.
A service might be rewritten in another language while retaining its API and dependencies. The implementation changes; the role in the system can remain recognisable. That lets engineers reason about a failure without memorising every recent code change.
The purpose of repeated drawing was to keep that mental model shared across the team.
Configuration Distribution
A second example covered a small-data configuration service, transcribed in my notes as “Convigly”. The name is uncertain; the architecture was a three-layer sketch:
- A Redis-compatible backend.
- A proxy layer in front of it.
- Many client processes connecting through the proxies.
One example of the distributed data was the set of datacentres available for inference and their GPU capacity.
Direct connections from every process had become difficult to manage. The proxy and client-library layers controlled access patterns and blocked expensive operations that could overload the backend.
The drawing also crossed team boundaries. Some clients belonged to other teams, but the reliability team still needed to understand their behaviour when something broke.
Compare the Team's Drawings
Murali proposed having engineers draw their area independently, then putting the drawings beside one another.
Differences reveal what people include, omit, or assume. One person may draw a direct database connection while another expects a proxy. Both may have been reasoning carefully from different pictures of the same system.
Putting the drawings beside each other gives the team a chance to find that mismatch before an incident adds pressure to the conversation.
The exercise builds familiarity through repetition. During an incident, the value is having the system's structure in your head, rather than needing to produce a polished diagram while paged.
Reviewing Architectural Change
The session raised a possible review workflow: generate the architecture or call graph before and after a proposed change, then ask a person to review the changed relationships.
A new dependency or component boundary deserves attention even when the implementation diff looks routine. This was a proposed direction for review, not a replacement for checking code, behaviour, or permissions.