I am expanding this second brain with a structured view of AI‑native product building. The focus is on turning AI from a feature into a participant that lives inside team workflows, using a persistent knowledge graph that links AI interaction logs to work artefacts and preserves provenance, identity and sharing boundaries. The product‑building principles I follow are: start from real workflows, treat context as infrastructure, preserve provenance, give agents identity, connect AI activity to outcomes, pair automation with quality control, use design partners to surface pain, be precise with metrics, prioritize real feedback over vanity, and let value grow from structured experience rather than raw data volume.
A useful early-stage question is not just "Would you use this?" but "Where does your current workflow break because the system does not know enough context?"
I use this page as a public second brain: a collection of ideas, lessons, frameworks, and working principles from my conversations and product-building work that I believe can be useful to other builders. I am interested in the shift from AI as a feature to AI as a participant in how teams work.
Tools such as Slack, GitHub, Linear, Cursor, Claude Code, and ChatGPT each capture pieces of that picture, but the pieces are fragmented.
The idea behind xysq.ai is to connect those pieces into a shared knowledge graph for a company.
I care about the gap between AI activity and shipped outcomes.
A context layer can therefore be thought of as infrastructure for AI agents: persistent memory, provenance, identity, sharing boundaries, and retrieval are all part of the system.
Making a system faster is not enough if users cannot trust its output.
Build systems that become more useful through accumulated, structured experience rather than simply accumulating more raw data.
In the workflows I worked on, this reduced annotation time by about 10x at the median.