Domain Understanding is Moat. - by sohit kumar
sohit’s Newsletter
SubscribeSign in
Domain Understanding is Moat.
sohit kumar<br>May 28, 2026
Share
We have been hearing a lot about what the moat is. Some say the harness is the moat. Some say the model is the moat. It keeps changing every day.<br>What I believe is - the moat is domain understanding.<br>Thanks for reading sohit’s Newsletter! Subscribe for free to receive new posts and support my work.
Subscribe
Domain understanding means knowing the customer’s workflows, constraints, edge cases, goals, failure modes, and what “good” actually means in their world.<br>You encode domain understanding into software.<br>Earlier, you encoded domain knowledge into workflows, databases, and CRUD APIs packaged as SaaS. The knowledge you were able to capture was limited because you could only read/write data and represent it through workflows. That is why we needed humans to work on top of SaaS to provide additional domain understanding which we could not encode.<br>Today, that domain understanding is being encoded in evals, prompts, and harnesses.<br>When folks say the harness is the moat - they mean that during compaction, when you hit the context window, it is important to have past summaries to meet the outcome, so you use summarisation instead of a sliding window. This is nothing but domain understanding encoded in the harness. Claude Code’s harness understands the coding domain really well.<br>When folks say the model is the moat - they mean encoding domain understanding into model weights because we need to deliver value quickly and latency is important.<br>And may be tomorrow we can have specific chips which will help optimize and solve problem in certain domain.<br>But you get the idea. It is all about understanding the domain to deliver value to the customer. The shape and form can keep changing.<br>More you understand that, more value you can provide value to the customer. This is business 101 - provide value to the customer.<br>This why you want to have feedback loop - iterate fast and get feedback from customer/traces so that you can understand more about the domain you are operating in and encode that into your software and offload work from them as much as possible and provide more value. Feedback loop compounds your moat.<br>And when you have constraints, you pick the best place to encode that domain understanding.<br>If training a model does not make business sense because of Capex, you encode it elsewhere: in the harness, prompts, skills, evals, memory, and context layer.<br>The form changes. The goal stays the same - capture domain understanding and deliver value to the customer.<br>The moat is how much domain understanding you can capture, encode, and compound inside the product.<br>Thanks for reading sohit’s Newsletter! Subscribe for free to receive new posts and support my work.
Subscribe
Share
Discussion about this post<br>CommentsRestacks
TopLatest
No posts
Ready for more?
Subscribe
© 2026 sohit kumar · Privacy ∙ Terms ∙ Collection notice<br>Start your SubstackGet the app<br>Substack is the home for great culture
This site requires JavaScript to run correctly. Please turn on JavaScript or unblock scripts