You are browsing as a guest. Sign up (or log in) to start making projects!

satvikhardat

@satvikhardat

Joined June 2nd, 2026

  • 7Devlogs
  • 7Projects
  • 1Ships
  • 15Votes
Security researcher | ethical hacker | top 100 worldwide GoogleVRP | Hall of fame crypto.com, MTN Group, GoogleVRP
Open comments for this post

5h 0m 34s logged

Devlog 1: Building OpenAgent

I’m working on OpenAgent, a framework for creating reconfigurable teams of AI agents that can work together like a real organization. The idea is not to build another chatbot or another fixed “researcher + coder + writer” agent setup.

Instead, OpenAgent starts with two core agents:

  • Boss Agent — understands the mission, plans the team, breaks work into small focused tasks, and integrates everything.

  • Critic Agent — reviews the Boss, watches all worker agents, catches mistakes, blocks weak work, and makes sure agents do not slack off or hallucinate.

After that, the Boss can dynamically create the right temporary agents for the task.

For example, if the mission is:

“Build a backend API for agent orchestration.”

The Boss might create separate agents for every single feature requested, Auth dev agent, DB setup agent, schema planner, and documentation.

Each agent focuses on a tiny part in depth.

The Critic reviews their outputs, checks if they followed the goal, and rejects vague or low-quality work.

Then the Boss ensures everything combines to one clean final result.

The main goal of OpenAgent is to make AI agents less like random chatbots and more like a coordinated team: planned, reviewed, steerable, and accountable.

Devlog 1: Building OpenAgent

I’m working on OpenAgent, a framework for creating reconfigurable teams of AI agents that can work together like a real organization. The idea is not to build another chatbot or another fixed “researcher + coder + writer” agent setup.

Instead, OpenAgent starts with two core agents:

  • Boss Agent — understands the mission, plans the team, breaks work into small focused tasks, and integrates everything.

  • Critic Agent — reviews the Boss, watches all worker agents, catches mistakes, blocks weak work, and makes sure agents do not slack off or hallucinate.

After that, the Boss can dynamically create the right temporary agents for the task.

For example, if the mission is:

“Build a backend API for agent orchestration.”

The Boss might create separate agents for every single feature requested, Auth dev agent, DB setup agent, schema planner, and documentation.

Each agent focuses on a tiny part in depth.

The Critic reviews their outputs, checks if they followed the goal, and rejects vague or low-quality work.

Then the Boss ensures everything combines to one clean final result.

The main goal of OpenAgent is to make AI agents less like random chatbots and more like a coordinated team: planned, reviewed, steerable, and accountable.

Replying to @satvikhardat

0
28
Open comments for this post

49m 33s logged

The variants now work properly they were doing dumb stuff before, because i accidently made a wrong assumption over the ambiguity of proto payloads

The variants now work properly they were doing dumb stuff before, because i accidently made a wrong assumption over the ambiguity of proto payloads

Replying to @satvikhardat

0
8
Open comments for this post

16m 1s logged

Default page for my blog done! Jekyll is confusing but not the hardest

Default page for my blog done! Jekyll is confusing but not the hardest

Replying to @satvikhardat

0
12
Ship

# What did I make?

I made a live schemaless Protobuf editor for hackers, bug bounty hunters, reverse engineers, and API testers. The idea is simple: paste a raw Protobuf blob, usually base64 or hex, decode it into a JSON-like view with numeric field IDs, edit the JSON, and instantly get the updated Protobuf output back.

It is basically like protoc --decode_raw, but editable, visual, and easier to use.

# What was challenging?

The hardest part is that raw Protobuf without a schema is ambiguous. A field might be a string, raw bytes, a nested message, a number, a boolean, an enum, or packed repeated values. Since the tool does not always know the real type, I had to think about how to show possible interpretations without making the UI confusing.

Another challenge was making the edit-and-reencode flow feel simple, because Protobuf is not naturally as easy to modify as JSON.

# What am I proud of?

I’m proud that the project solves a real problem I personally face while doing security research. A lot of Google and large-scale APIs use base64 encoded Protobuf everywhere, and editing even one field usually requires random scripts or complex CLI tools.

This project makes that workflow much faster: paste, decode, edit, re-encode, test.

# What should people know so they can test it?

You do not need a .proto schema to try it. Paste a base64 or hex Protobuf payload, and the editor will attempt to decode it into numeric field JSON like "1", "2", "3", etc.

Because raw Protobuf is ambiguous without a schema, some fields may have multiple possible meanings. That is expected. The goal is not to magically know everything, but to make raw Protobuf easier to inspect and edit.

  • 5 devlogs
  • 2h
Try project → See source code →
Open comments for this post

24m 2s logged

I am a ethical hacker and a bug bounty hunter, currently top 100 on google vrp, whenever i want to hack google based targets, they use protbuf everywhere i see like every single place, its all just protobuf encoded as base64, but the CLI tools that we have to decode and edit protobuf are too complex, like if you wish to just edit a single field in a proto blob, you would have to ask chatgpt to write a whole script using some random magicaly proto lib that i never seemed to understand, so instead i thought why not have a live mode editor that can show you the json of a pasted proto blob and you can easily edit the json and the changes would refect to the proto.

Right now, the workflow is painful.

You copy the base64 blob, decode it, run something like protoc --decode_raw, stare at numeric field IDs, guess what each field means, then if you want to modify even one field, you usually need to write a custom script with some random Protobuf library. Most of the time I end up asking ChatGPT to generate a Python script, then debugging that script, then trying to re-encode the payload correctly.

The idea is simple:

Paste a Protobuf blob, decode it into a JSON-like structure, edit the JSON, and instantly get the updated Protobuf output back.

No schema required.

The main mode will be schemaless. If the payload has fields like 1, 2, 3, the editor should show them as editable JSON keys. For example:

{
“1”: “satvik”,
“2”: 16,
“3”: true,
“4”: {
“1”: “nested-value”
}
}

Then if I change field 2 from 16 to 17, the Protobuf output should update automatically.

The hard part is that Protobuf without a schema is ambiguous. A length-delimited field could be a string, raw bytes, a nested message, or packed repeated values. A varint could be an integer, boolean, enum, or something else. So the editor needs to show possible interpretations instead of pretending it knows everything.

This is mainly built for bug bounty hunters, reverse engineers, API testers, and developers who work with Protobuf APIs but don’t want to fight CLI tools every time they need to edit one field.

The end goal is:

Edit raw Protobuf like JSON. No schema required.

(attached image is a protbuf response from a google api, you can see why its hard to work with protobuf)

I am a ethical hacker and a bug bounty hunter, currently top 100 on google vrp, whenever i want to hack google based targets, they use protbuf everywhere i see like every single place, its all just protobuf encoded as base64, but the CLI tools that we have to decode and edit protobuf are too complex, like if you wish to just edit a single field in a proto blob, you would have to ask chatgpt to write a whole script using some random magicaly proto lib that i never seemed to understand, so instead i thought why not have a live mode editor that can show you the json of a pasted proto blob and you can easily edit the json and the changes would refect to the proto.

Right now, the workflow is painful.

You copy the base64 blob, decode it, run something like protoc --decode_raw, stare at numeric field IDs, guess what each field means, then if you want to modify even one field, you usually need to write a custom script with some random Protobuf library. Most of the time I end up asking ChatGPT to generate a Python script, then debugging that script, then trying to re-encode the payload correctly.

The idea is simple:

Paste a Protobuf blob, decode it into a JSON-like structure, edit the JSON, and instantly get the updated Protobuf output back.

No schema required.

The main mode will be schemaless. If the payload has fields like 1, 2, 3, the editor should show them as editable JSON keys. For example:

{
“1”: “satvik”,
“2”: 16,
“3”: true,
“4”: {
“1”: “nested-value”
}
}

Then if I change field 2 from 16 to 17, the Protobuf output should update automatically.

The hard part is that Protobuf without a schema is ambiguous. A length-delimited field could be a string, raw bytes, a nested message, or packed repeated values. A varint could be an integer, boolean, enum, or something else. So the editor needs to show possible interpretations instead of pretending it knows everything.

This is mainly built for bug bounty hunters, reverse engineers, API testers, and developers who work with Protobuf APIs but don’t want to fight CLI tools every time they need to edit one field.

The end goal is:

Edit raw Protobuf like JSON. No schema required.

(attached image is a protbuf response from a google api, you can see why its hard to work with protobuf)

Replying to @satvikhardat

0
1

Followers

Loading…