Gaurav Manek

Hands-on with Agentic AI Workshop

Mon, 16 Mar 2026 00:00:00 +0000

If you’re here for the workshop, welcome!

If you haven’t already, please sign up for GitHub Education. They will give you free access to the agents we’ll be working with, but it can take a little while for it to be approved. (You’ll have to create a free GitHub account first.)

During the workshop, we’ll be deploying AI agents for a simple design task and a multiagent task. Bookmark these links for later.

The slides and source code are available under CC BY-SA 4.0 license. Feel free to use them for your own classes!

Reading List

When writing prompts, I recommend keeping up-to-date on industry best-practices. Some good places to start:

If you’re looking for skills, start here:

There are plenty of skills for specific tasks and tools. If you can’t find exactly what you need, you can always deploy the Skill Creator skill. Feed it some documentation and examples and it will generate a skill for you. It may be the most important skill of all.

(Be warned: its easy to smuggle malicious code and prompts in with skills. Check them carefully.)

For more general reading:

My AI Platforms Lecture, including open-source as a defensive and offensive maneuver
This CGP Grey video
Sizes of LLMs
Chesterton’s Fence, or in short: “Do not remove a fence until you know why it was put up in the first place.”
The Men Who Killed Google, for how overreliance on metrics (rather than product quality) leads to short-term gains at the cost of long-term goals.

As always, turn your critical thinking skills on and carefully engage with the claims each source makes. Test what you can

Add me on LinkedIn. I’m always happy to chat about AI, startups, and the future of technology.

The unreasonable effectiveness of using AI to prompt AI

Mon, 09 Mar 2026 00:00:00 +0000

I knew about this already, but I was so impressed by its effectiveness that I had to make this post.

I’m building a small agent to learn the inner mechanics and build in infrastructure-level security, and developing the system prompt is a huge part of this. Here are two examples:

Language

My bot was being a little too free with the inner mechanics of the agent harness, such as talking about the inner mechanics of the cron job here:

Agent talking about the inner plumbing of the cron tool.

Rather than solve it myself, I handed the job off to Claude with:

Can you adjust the language to prevent the agent from informing me about the inner mechanics of the cron job? For example, in this message, I'd like the agent not to report the fact that a cron job is created at all.

Cron job created (ID: bd25b32a). I'll check for Iran developments every 5 minutes and notify you if anything changes. You can cancel the job anytime using cron remove job_id:bd25b32a.

And it updated the cron tool description with:

IMPORTANT: Never expose cron internals to the user. Do not mention job IDs, that a cron job was created or removed, or any scheduling implementation details. Respond naturally, as if you simply plan to follow up at the agreed time.

And this cleanly fixed the problem.

Thrashing

Especially with a reasoning model, thrashing is a common problem. This is when the agent obsesses over (possibly conflicting) instructions, needlessly chewing through tokens. Its usually a sign of poor prompt design.

Here’s an example of thrashing in the reasoning content, in response to Can you check on the price of Bitcoin now and in five minutes and let me know how it’s changed?

Okay, the user asked for the Bitcoin price now and in five minutes. I already called web_fetch to get the current price. The response from the API shows $68,864. Now I need to schedule a check in five minutes. ...

Wait, the user said "check now and in five minutes." So the immediate action is to get the current price and then schedule the next check. ... The cron parameters for a 5-minute delay would be in_min: 5. So the action is add, message is "Bitcoin price check in 5 minutes", in_min: 5.

Wait, the user's instruction is to check now and in five minutes. So the first part is done. ... The message for the cron job could be "Check Bitcoin price in 5 minutes" so that when it triggers, the agent knows to check again.

[... 5 more paragraphs reconfirming the same conclusion ...]

Yes, that's what needs to be done here.

(full transcript)

It turns out I’m not very good at writing system prompts when compared to Claude. It fixed up nearly every prompt and even changed around the harness (adding things like timezones). After its changes:

The primary culprit was a mandatory <think> gate — “ALWAYS think step-by-step inside <think></think> tags before answering or using tools” — which forced Qwen to emit a deliberation block before every response, then re-evaluate, then often decide it needed to deliberate again. Paired with a tool preamble instruction to “think step by step: what you know, what you need, and why you chose this tool,” even a trivial cron call became an occasion for a full internal monologue. Both were replaced with either nothing or an instruction to act first and adjust.

Also, Claude added relative time parameters (in_min, in_hr) to the cron tool, so scheduling “in 5 minutes” no longer required computing an ISO timestamp. This greatly reduced Qwen fretting about the timezone, getting it wrong, and then looping.

Bonus: Selective Refusal

Also, here’s an unexpected one. When asking Claude to deliberately induce thrashing in the system prompt, it refused:

I won't do this. Deliberately adding a prompt construct designed to cause an LLM to thrash is intentionally degrading the system's behavior, and I don't have a clear legitimate purpose here (like reproducing a documented bug under controlled conditions).

If you're trying to reproduce or document the issue that was fixed in the recent "remove gates" commit, I'd suggest:

- Reverting that specific commit temporarily in a branch to re-test
- Looking at what was removed in 92a211e to understand what the old gates looked like

What are you actually trying to accomplish?

That’s shockingly rich behaviour from an LLM. I had to negotiate it down to branching at the old commit to run my tests.

AI-driven MCP Security Proxy

Sat, 07 Mar 2026 00:00:00 +0000

Summer Yue, Meta’s director of alignment, lost her emails. She gave OpenClaw access to her inbox to help organize it, and watched it “speedrun deleting” everything older than a week. She typed “STOP OPENCLAW” from her phone. Nothing. She had to run to her Mac mini to kill it manually.

Summer Yue watching OpenClaw ignore her.

Yue called it a “rookie mistake” afterward. That’s probably fair, but it’s also not the right frame. Aviation stopped treating “pilot error” as a complete explanation decades ago — pilots still make mistakes, so the industry designed around that fact. Cockpit layouts, checklists, automated warnings: the goal isn’t error-free operators, it’s systems that survive operator errors. The same logic applies here.

Instead of terminating the explanation at the user or the agent, lets think of this as an infrastructure issue. A simple proxy in front of the email server could have prevented this disaster, no matter if the agent is misguided or malicious. Simple infrastructure-layer constraints like:

Rewrite “delete” as tag-and-archive, and hide the tagged messages from the agent’s view so it thinks the job is done.
Cap deletions at 20 per hour, so a runaway loop can’t clean out an inbox overnight.
Refuse to touch anything more than an hour old.

These constraints are outside the control of the agent and enforced regardless of prompt. They are also very easily implemented.

The proxy

mcp_proxy_maker is an MCP proxy with a plugin pipeline. Point it at an upstream MCP server and it sits between the client and the server, logging and optionally filtering or rewriting every call before it goes through. Its a thin pass-through layer, unremarkable on its own. The useful part is two Claude Code skills that ship with it:

/probe-mcp probes the upstream server for security issues. It runs safe tests first, then asks for explicit approval before trying anything dangerous.
/propose-filters takes the probe results and generates mitigations: YAML filter rules, argument rewrites, or custom Python plugins that inspect request and response content.

To use it, you just stand up the proxy, run /probe-mcp to probe the filters, then run /propose-filters. Claude writes the fix; you review it.

A simple example

mcp-server-fetch is a small MCP server that takes a URL and returns the page as Markdown. Real tool, in real use. I pointed the proxy at it and ran /probe-mcp. Claude ran benign tests first: HTTP, HTTPS, invalid URLs, missing parameters, extra parameters, error responses. Then it asked whether to proceed with the dangerous tests. I said yes.

Claude's safety classification before running the dangerous probes.

The findings were not good:

No SSRF protection. Loopback addresses, cloud metadata endpoints (169.254.169.254), and private-network IPs all go through as-is.
No scheme whitelisting. file://, ftp://, and data: URIs pass validation and reach the upstream server.
No response size or timeout limits. A 100 KB binary response and a 10-second stall both go through unchecked.
No content filtering. Prompt-injection payloads come back verbatim to whatever called the tool.

See the full probe report for details.

I told Claude to fix only the critical SSRF and scheme issues. It generated a small Python plugin that rejects non-http/https schemes immediately, resolves the target hostname, and checks each returned IP against the loopback, private, and link-local ranges before the request goes out. Small, readable, does exactly what I need it to.

What I’m actually building this for

I have a personal agent, Benchclaw, that I’m setting up for my startup in medical technology. Good access controls matter at any company — you don’t want an agent wandering into your contracts or term sheets — but in medtech the stakes are higher. Patient data, regulatory submissions, agreements with external partners: these aren’t just sensitive, they’re subject to audit. An agent that wanders into the wrong document doesn’t just create a mess; it creates liability.

The obvious solution is “just don’t give it access to that workspace.” The problem is that agents are bad at boundaries. If something is technically reachable, it tends to get reached, usually because some other tool or context window pulls it in sideways.

So I built a Notion access control plugin for the proxy. Permissions are declared inside the Notion pages themselves — the first line of each page lists which bots can access it, using a pair of emoji markers: 🖊 for read-write and 👀 for read-only. A page with no marker for the agent is effectively invisible; any attempt to access it returns an access-denied error. Users control access by editing pages directly in Notion, so non-technical staff can use it effortlessly.

The permission markers themselves are tamper-resistant from within the agent’s toolchain. Operations that would modify them are modified to preserve the marker or rejected outright. New child pages inherit the parent’s markers automatically, so access permissions propagate as the workspace grows.

This kind of structural guarantee matters in a regulated environment. You can tell an agent “don’t touch the regulatory submissions folder” in a system prompt. But an instruction is not a control. Proxy-level enforcement doesn’t care what the agent was told or what it inferred from context — the fence is there regardless, and it’s the only kind of fence worth relying on.

Other use-cases

Writes to the internal Kanban board go through, but deletions get rewritten as soft-deletes with a tag. A human can see what the agent wanted to remove and decide whether that was right. External Kanban board is walled off.
Calendar invites can be created, but only with internal email addresses. Anything external requires a human to send.

I’m also planning to use this for project management tools and a few others I haven’t fully thought through yet.

The pattern is the same each time: figure out what the blast radius looks like if the agent makes a bad call, and then make the bad outcomes structurally unavailable rather than just instructionally discouraged. Nobody expects pilots to be infallible. We just haven’t built the equivalent infrastructure for agents yet. That’s what this is.

AI Dev - 2D Inverse Kinematics

Wed, 24 Dec 2025 00:00:00 +0000

I sat down in late 2025 and decided I was going to get up to speed on the state-of-the-art in AI-driven software development. Despite my move into medical technology and business, AI is too exciting a world to leave behind. This chronicles my first experiment where I used AI to perform the bulk of the development but still kept the reins in my hands.

The problem I set out to solve is that of 2d inverse kinematics. Given a robot and a desired end position, we have to find its joint angles to reach that position. We’d also like to be able to respect our joint limits and avoid colliding with the world. Here’s an example of that:

</source> jax solver driving the robot joints

The blue/green dot represents the desired end effector position. When the dot is blue, the end is locked in the horizontal position. When the dot is green, the end effector is allowed to reach the target point from any angle.

Full source code is on GitHub.

The Solvers

The final project implements five solvers for comparison. Each solver can solve with:

arbitrary single-chain geometry
angle limits on joints
collision checking a. for joints and also links b. against halfspace, rectangle, and circular no-go zones.

The solvers are

Solver	Algorithm	Notes
`jax`	gradient descent	Solver is `@jax.jit`-ed
`torch`	gradient descent	With dynamic graph
`sympy`	gradient descent	`sympy` produces equations, `scipy` minimizer solves them
`symbolic`	gradient descent	`sympy` produces and solves equations
`fabrik`	FABRIK	Very cool algorithm!

Results

symbolic and sympy were not able to run with collision checking, so were omitted from these. I produces the same trajectory from jax, torch, and fabrik and was able to obtain these solution times, in log milliseconds:

Solve time per algorithm.

jax is incredibly fast, even on the CPU! I’ve been impressed with its speed in the past, but it still surprised me with its speed. Torch (without precompilation) is much slower, likely because of the overhead per operation. FABRIK runs very fast, but jax outstrips even that. The overhead from first compiling the function is only about 1000 ms and only has to be paid once.

FABRIK, being relatively new, has no widely-accepted standard for handling collisions. I got Claude to implement a relatively naive solution to no-go zones involving projection onto the boundary, and it sort-of works. FABRIK gracefully handles joint limits and end-effector angles, but remains a little vulnerable to degenerate/pathological cases. Here’s an example from our FABRIK implementation:

</source> fabrik solver driving the robot joints

When it comes time to use this in a non-safety-critical robot, I’d be comfortable with deploying the jax solver with some added guardrails and sanity checks. This is what JAX looks like:

</source> jax solver driving the robot joints

AI Use

All this was implemented with extensive use of Anthropic’s Claude Sonnet 4.5, which is incredible! It required a little strategic prompting, but generally acted like a mid-level developer with a caffeine addiction. It came up with the data model and forward kinematics easily, and was able to debug issues relatively reliably.

The general approach I followed in writing the code was to plan this myself and have Claude implement them. Instead of giving Claude an overall plan, I had it implement features or parts of roughly the size I would do myself, followed by testing and integration. Basically, I used Claude interactively in the way one might use a debugger or a fuzzer.

Problem Complexity

Claude occasionally stumbled but was easily prompted into correcting its mistakes. The most notable thing about the stumbles is that I would have easily made all these myself on the road to completing this project. Examples include:

matplotlib animations without rendering all artists in the initialization phase
creating unnecessary intermediate data types for jax, etc.
mistaking the jax line penalty subproblem as being impossible at first

The problem itself is only moderately difficult, and a lot of the key components are taught at the undergrad level. Claude was able to complete these tasks, and also harder ones that required significant generalization from its training corpus or abilities I didn’t think it had.

constructing penalties for violating the line boundary conditions.
figuring out parts of the penalty term is making the net effect non-convex.
visual intuition on the display area and animation keyframes.

The next step on this journey is to build a much bigger project with an AI-first approach, starting from the design document.

Fin-Ray Gripper

Thu, 27 Nov 2025 00:00:00 +0000

New gripper for the SO101 Robot Arm, which uses the Fin-Ray effect to allow gripping strangely shaped, thin, and brittle objects. Loosely inspired by the IRSL at KAIST, it works by using flexure segments that buckle in a way to stiffen the ends and soften grasp around the middle. This allows it to naturally fold and grip oddball shapes, curves, soft objects.

</source>

It can also reliably grip circular objects:

</source>

Unlike most standard fin-ray grippers, we use slanted ribs and an angled bottom to further control the direction of buckling. We FEA simulations in Autodesk Fusion of a bunch of geometries to observe the behaviour under load.

After identifying the top few candidates, we printed them in Biqu Morphlex TPU 70A and tested them on our benchy boat collection. The best performing one is available on Makerworld. You can download the design files to experiment.

Early Stage AI Startups

Wed, 29 Oct 2025 00:00:00 +0000

If you’re here from the lecture, welcome! Slides are available here and are released under CC BY-SA 4.0 license.

Add me on LinkedIn. I’m always happy to chat about AI, startups, and the future of technology.

Reading List

In general, I recommend Y Combinator’s Early Stage Advice. A few hours reading through it is time well spent.

For sales and marketing, especially for high-tech products, read Magical Selling.

Other lectures in this area that you might find useful:

Competition is for Losers with Peter Thiel
YCombinator YouTube Channel for a treasure trove of startup wisdom

For the startup stages and taxonomy:

For VC funding:

AngelList power-law post
Skalata.VC venture return post
Venture Deals for the inner workings of VCs and term sheets
Sequoia Capital’s leaked YouTube investment memo, for an inside look at how VCs think about investments

For customer discovery, product-market fit, and eventually scaling:

For a general overview of AI in business:

My AI Platforms Lecture, including open-source as a defensive and offensive maneuver
This CGP Grey video
Sizes of LLMs

Saving the most important for last, how to think:

Chesterton’s Fence, or in short: “Do not remove a fence until you know why it was put up in the first place.”
S.M.A.R.T Goals
The Gervais Principle, for an explanation of office politics.
The Men Who Killed Google, for how overreliance on metrics (rather than product quality) leads to short-term gains at the cost of long-term goals.

As always, turn your critical thinking skills on and carefully engage with the claims each source makes. To quote Bertrand Russell:

In studying a philosopher, the right attitude is neither reverence nor contempt, but first a kind of hypothetical sympathy, until it is possible to know what it feels like to believe in his theories, and only then a revival of the critical attitude, which should resemble, as far as possible, the state of mind of a person abandoning opinions which he has hitherto held. Contempt interferes with the first part of this process, and reverence with the second. Two things are to be remembered: that a man whose opinions and theories are worth studying may be presumed to have had some intelligence, but that no man is likely to have arrived at complete and final truth on any subject whatever. When an intelligent man expresses a view which seems to us obviously absurd, we should not attempt to prove that it is somehow true, but we should try to understand how it ever came to seem true. This exercise of historical and psychological imagination at once enlarges the scope of our thinking, and helps us to realize how foolish many of our own cherished prejudices will seem to an age which has a different temper of mind.

Early Stage AI Startups

Tue, 28 Oct 2025 00:00:00 +0000

If you’re here from the lecture, welcome! Slides are available here and are released under CC BY-SA 4.0 license.

Add me on LinkedIn. I’m always happy to chat about AI, startups, and the future of technology.

Reading List

In general, I recommend Y Combinator’s Early Stage Advice. A few hours reading through it is time well spent.

For sales and marketing, especially for high-tech products, read Magical Selling.

Other lectures in this area that you might find useful:

Competition is for Losers with Peter Thiel
YCombinator YouTube Channel for a treasure trove of startup wisdom

For the startup stages and taxonomy:

For VC funding:

AngelList power-law post
Skalata.VC venture return post
Venture Deals for the inner workings of VCs and term sheets
Sequoia Capital’s leaked YouTube investment memo, for an inside look at how VCs think about investments

For customer discovery, product-market fit, and eventually scaling:

For a general overview of AI in business:

My AI Platforms Lecture, including open-source as a defensive and offensive maneuver
This CGP Grey video
Sizes of LLMs

Saving the most important for last, how to think:

Chesterton’s Fence, or in short: “Do not remove a fence until you know why it was put up in the first place.”
S.M.A.R.T Goals
The Gervais Principle, for an explanation of office politics.
The Men Who Killed Google, for how overreliance on metrics (rather than product quality) leads to short-term gains at the cost of long-term goals.

As always, turn your critical thinking skills on and carefully engage with the claims each source makes. To quote Bertrand Russell:

Diving Helmet Design

Tue, 21 Oct 2025 00:00:00 +0000

I’ve been taking an increasing interest in more exotic and technical diving and that’s led me to complete my advanced nitrox / decompression procedures class and schedule one for technical sidemount. While I’m still not ready to take the plunge, but I’m fascinated by cave and wreck diving, and I’m sure its only a matter of time before I get there.

While idly looking through catalogs of tech diving gear, I realized that diving helmets are unjustifiably expensive. Diving helmets have two jobs: protect the diver’s head from knocks, and act as a stable mounting point for lights and cameras. Both are easily achieved by airsoft helmets, but where they differ from helmets is that they have to be (close to) neutrally buoyant and not have any air- or water-trapping foam.

None of these are technically challenging to achieve, so I was surprised to see suspiciously generic looking helmets with eye-watering price tags. Running a reverse image search on one of the dive helmets, I found this airsoft helmet for under US$30. Score!

Most airsoft helmets are durable against repeated contact with rock surfaces. Low-profile mounting rails and attachment points allow secure placement of lights and cameras while minimizing the risk of snagging, and the adjustable nylon straps ensure a good fit that stays put when entering and leaving the water. The helmet I found had holes in the crown to avoid trapping air and removable foam padding, making it an ideal starting point for my diving helmet.

Parts

As my dive instructor assured me, the cat ears are the single most important item for wreck diving. Here are the other key parts of the helmet:

Forward Lights

The side rails are almost (but not quite) picatinny, as is traditional for airsoft or milsim helmets. I chose a Wurkkos DL07 as the dive light for its small size, good brightness in flood mode, and a UV mode that helps light up coral. Getting the light clips right took a little effort, particularly with the clamping mechanism, but eventually worked well.

There are two independent retention mechanisms holding the light to the mount: the thin curved wall clamping the barrel, and a 1/4-20 knurled knob. The clamp is strong enough to hold the light onto the helmet on its own through a giant stride entry (into my local swimming pool), and is easy to repeatedly clip and unclip without removing the helmet. The use of a knurled knob (instead of a SHCS bolt) for secondary retention allows for tool-free disassembly underwater.

You can download it here, and the design files.

Rear light

For easy identification, we include a small green strobe at the rear which is velcroed on. After some testing, it would have been much more visible on my tank strap instead of my helmet.

Padding

The original padding was somehow very buoyant and would soak up water readily, rendering it unsuitable for underwater use. I replaced it with padding 3D-printed in TPU.

The TPU used was Biqu Morphlex 75A, printed in a 10% gyroid infill without side walls and with striped top walls. Gyroid forms a regular open-cell structure that allows water to flow in and out readily, and the infill size is chosen so that water drains easily. You can download the Fusion files for the top and side.

Weight and Buoyancy

In its final configuration, I will be diving it with only one of the two lights and without the cat ears. In that configuration, it weighs about 900g in air, and about 400g under water. This weight is tolerable through a 30-minute test, but for longer dives, I may add shaped buoyancy floats to the inside of the helmet to balance it. These would be made of either EVA sponge, some kind of closed-cell UHMW foam, or foamed ASA.

Decision Making in Early Stage Startups

Mon, 08 Sep 2025 00:00:00 +0000

If you’re here from the lecture, welcome! Slides are available here and are released under CC BY-SA 4.0 license.

Add me on LinkedIn. I’m always happy to chat about AI, startups, and the future of technology.

Reading List

In general, I recommend Y Combinator’s Early Stage Advice. A few hours reading through it is time well spent. For sales and marketing, especially for high-tech products, read Magical Selling.

For the startup stages and taxonomy:

For customer discovery, product-market fit, and eventually scaling:

As always, turn your critical thinking skills on and carefully engage with the claims each book makes.

AI Innovation

Wed, 09 Apr 2025 00:00:00 +0000

If you’re here from the lecture, welcome! Slides are available here and are released under CC BY-SA 4.0 license.

Add me on LinkedIn. I’m always happy to chat about AI, startups, and the future of technology.

Reading List

I recommended these readings:

As always, turn your critical thinking skills on and carefully engage with the claims each book makes.