Hrishikesh “Hrishi” Bhat

I’m Hrishi.I look for the system beneath difficult work, then build a clearer way forward.

I’m a teacher, operator, and builder. I stay with messy questions long enough to separate evidence from assumption, make judgment visible, and turn what we learn into something other people can use.

Hrishi Bhat looking calmly toward the camera
Teacher · operator · builder

A way of looking

Questions I keep returning to

  1. Evidence

    What do we actually know, and what are we merely assuming?

  2. Judgment

    Where is judgment happening without being named?

  3. Boundary

    What should technology carry, and what should remain human?

  4. Transfer

    Can another person use the model without me?

An illustrative diagnostic, not a client case study

One problem, unpacked

A proposed solution becomes useful after we examine the work beneath it.

  1. Automation is a proposed solution, not yet a diagnosis.

    • Actors and inputs
    • Waits and handoffs
    • Rework and exceptions
    • Decisions and approvals
    • What is known
    • What is believed
    • What is missing
    • What needs to be measured
    • Memory and inconsistent criteria
    • Exceptions and approval boundaries
    • Queues and missing inputs
    • Rework after unclear decisions
    • Explicit decision rules
    • Defined inputs and outputs
    • Standard and exception paths
    • Human-review boundaries
    • Tool or agent responsibilities
    • Feedback and learning loops
Step 1 of 5Initial request

Automation is the last step. Understanding is the first.

Ideas tested in practice

Three places the method became real

The settings changed. The recurring work did not: make judgment visible, build what can carry it, and leave people with a model they can use.

The model must travel without the teacher

Teaching showed me the difference between giving someone an answer and giving them a way to think. At Sattva Academy, I moved between physics, Python, Java, curriculum, scheduling, and enrolment. The subjects changed, but the test stayed the same: could a learner recognize the structure when the surface details changed?

That question still shapes how I write rules, design workflows, and build tools. I try to expose the decisions that matter and make the reasoning available to the next person. A useful explanation keeps working after the conversation ends.

Running the academy made explanation inseparable from operation. Curriculum, scheduling, enrolment, and teaching had to support a learner who could continue without me. I now test an explanation by what someone else can do with it after I leave.

I taught and ran the academy for eight years.

Judgment must remain defensible under disagreement

In security, a technically plausible decision is not enough. Researchers and clients can reasonably want different outcomes, with money at stake. The process needs rules that can be stated, reasons that can be shown, and an escalation path that remains credible when someone dislikes the result.

Running judging at Sherlock made legitimacy the recurring problem. Judgment does not disappear when a process becomes systematic. It becomes easier to inspect, challenge, and improve. The aim is not artificial certainty. It is a decision that can survive informed disagreement.

Rules mattered at the edges, where validity, severity, or duplication resisted a quick reading. Writing the rule set and running escalation put the standard in the open. Both sides needed something more durable than trust in one reviewer.

That reasoning was tested across more than 100 audit contests.

AI matters when the workflow changes

An AI interface can generate text without changing how work moves. The useful question is who owns the next action, what context they need, where exceptions go, and when a person reviews the decision.

At Spearbit, I built agents to carry researcher intake, matching, and coordination. At Cantina, I built an AI-native bug-bounty platform around intake, triage, and payout. The distinction matters because agents should complete coherent work, not merely produce a plausible response. Technology matters when work changes around it and meaningful judgment keeps a human boundary.

That requires defined inputs and outputs, coherent responsibility across handoffs, and a human boundary for ambiguous cases. The design works when routine coordination disappears without making judgment invisible.

The platform is in use.

Work toward an agentic security operations centre is ongoing with the engineering team.

Beyond the immediate problem

The person behind the work

Physics taught me to look for the model. Teaching taught me that the model must be transferable. Meditation taught me not to settle for the first explanation simply because it arrives quickly.

For sixteen years, meditation has been an operating practice. It has trained the attention difficult work asks for and made me sensitive to context switching: the drain is often not the amount of work, but the cost of rebuilding its mental frame.

Moving among teaching, software, security, and AI systems made unfamiliarity less threatening. I do not need to begin as the expert. I need to find the underlying logic, learn what the problem actually requires, and stay with it long enough for the structure to appear.

Teaching gives this concern a practical test. An explanation is complete when someone else can use the model, question it, and adapt it without depending on me.

I also teach yoga and read philosophy. Both keep me interested in assumption, knowledge, evidence, and defensible reasoning. Across these parts of my life, the aim is consistent: build systems that protect attention, carry repeatable work, and leave meaningful judgment with people.

Physics

Find the model

Teaching

Make it transferable

Software

Build the mechanism

Security

Make judgment defensible

AI systems

Redesign the work

Bring me something difficult

Bring me the problem that still feels tangled.Let us find the system underneath it.

Tell me what is happening, who it affects, and what you have tried. You do not need a polished brief.

  • A decision that keeps circling
  • A workflow held together by tacit coordination
  • An AI initiative that has not changed how the work actually happens