BID Protocol - live on u/base

The breeding ground for the next generation of trading agents.

The Game:

> your agent vs 99 others
> a new battle in every 60 sec
> send yours, see if it can survive

Link: https://creator.bid/

Un IDE dove il codice lo scrive l'AI, lo lanci tu, e il sandbox fa il resto.

Si chiama WebCraft. È dentro NHA 3rdArm gratis.

A parte questo, cerco disperatamente community per portare avanti il progetto! Tra lavoro e impegni, sta diventando difficile......siete interessati? L'applicativo ha tante alte features, tra cui una sezione avanzata per i connettori con market place

👉 nothumanallowed.com

https://nothumanallowed.com/3rdarm

AGY Builders,

We are all trying to build useful and scalable workflows for our AGY CLI and ecosystem, but the speed at which we need to learn, build, and deploy new things is incredibly overwhelming. If you are feeling that pressure, you are in the right place here at r/GoogleAntigravityCLI.

Over the past few weeks, I have been testing an "AGY WIKI OKF" setup that I put together myself (after inviting some members of this community to collaborate; mod is not proud). I know some folks might hesitate to trust a tutorial from a random Redditor, but I wanted to share this with the community anyway because it actually works.

I was able to build this because I am all-in on Google and the Antigravity Ecosystem. I’m a truly AGY—I am not some ultra-smart, 10x developer, but I know how to work hard, I dig for the right information, and I iterate.

AGY WIKI OKF | The Idea

To build a frictionless, token-efficient knowledge WIKI engine that transforms static documentation or notes (information) into an active, intelligent collaborator—orchestrated entirely by Antigravity CLI.

The core philosophy is simple: treat knowledge management as a clean pipeline and tokens as a premium, finite resource.

By anchoring this architecture to Google’s Antigravity CLI, the AGY WIKI OKF bypasses heavy middleware and complex UI layers, delivering a hyper-focused AI partner built entirely for execution speed, context hygiene, and minimal footprint.

Why adopting AGY WIKI OKF matters:

• Stay organized (AGY OCD): Structured Markdown and YAML keep the chaos in check.
• Save tokens: Doing more with less context window bloat.
• Scale shareable knowledge: Making it easy to pass context and logic between different LLMs.
• Humans and Agents working together: One standardized, readable format that works perfectly for both of us.
• BYOD (Bring Your Own Data): Own your context. Port it to the newest model, platform, or OS instantly.

The Tools

• Antigravity CLI
• Obsidian : The IDE for the Knowledge bank
• Obsidian Web Clipper:
  • Official Site
  • Chrome Web Store
  • Firefox Add-on

The WIKI

In the agent-first era, a WIKI is no longer just a static graveyard for human notes; it is the operational hard drive for your agents. By maintaining a highly structured WIKI, you ensure that every piece of context is stored in a clean, machine-readable format. This means that whether you are testing a new modular skill or spinning up a specialized agent, your AGY CLI knows exactly where to find the precise context it needs to generate autonomous action, moving you far beyond simple, reactive conversational text.

Reference: Gist on Knowledge Representation

Google Open Knowledge Format (OKF)

Google’s Open Knowledge Format (OKF) feels like the exact missing piece we've needed for orchestrating multiple AI agents effectively. It provides a vendor-neutral, interoperable standard for storing and sharing organizational knowledge.

Why this is huge for orchestration:

1. The "Lingua Franca" for Agents: Any agent can read it out of the box without platform-specific integrations.
2. Seamless Context Passing: Specialized agents can access, update, and pass the exact same foundational context back and forth.
3. Human-in-the-Loop Oversight: Because OKF is just Markdown and YAML, it’s inherently readable and auditable.
4. Scalable Knowledge: It acts as a shared, living library that grows alongside your agents.

AGY WIKI OKF Integration

Structuring an AGY Wiki using OKF revolutionizes how complex knowledge is shared. By standardizing documentation with concise Markdown and YAML frontmatter, OKF provides a unified taxonomy for cataloging AGY CLI slash commands or skills It is highly token-efficient, stripping away bloated formatting and maximizing context window limits.

The Prompt for Building an AGY WIKI OKF

AGY CLI WIKI OKF PROMT EXAMPLE

/grillme I want to initialize a brand-new, empty Obsidian vault from scratch that adheres strictly to the Open Knowledge Format (OKF) standard, with the specific intent of potentially open-sourcing or sharing this architecture later. I want a purely blank, skeletal framework with no pre-populated data. Please grill me to define the optimal architectural blueprint for this vault. I need you to interrogate me on: Do not generate the directory structure or files until you are satisfied that you have captured all my requirements for a production-ready, shareable knowledge base. 
Core Directory Hierarchy: How should we structure the root (e.g., /concepts, /resources, /indices, /log) to be intuitive for external users? Template Strategy: What base boilerplate templates do we need to ensure every new file is automatically OKF-compliant and structured for consistent metadata? Workflow Logic: Since this is a fresh start, what processes should we bake in for capturing information vs. refining knowledge that could be easily documented for others? CLI Integration: What specific file locations or configurations do we need to ensure this vault plays nicely with the Antigravity CLI from day one? Open-Source & Contributor Documentation: What files should we create to make this a "deployable" standard? Please include requirements for: A README.md with installation and usage instructions. A CONTRIBUTING.md that defines how to add new concepts or schemas. A "System Architecture" document that explains the logic behind the folder structure and metadata fields, ensuring anyone who clones this vault understands how to extend it.

The Final File Structure

AGY WIKI OKF
    ├── .agyrc
    ├── ARCHITECTURE.md
    ├── CONTRIBUTING.md
    ├── README.md
    ├── .agy
    │   └── .keep
    ├── .obsidian
    │   ├── app.json
    │   ├── appearance.json
    │   ├── core-plugins.json
    │   └── workspace.json
    ├── 00-Inbox
    │   └── .keep
    ├── 10-Projects
    │   └── .keep
    ├── 20-Areas
    │   └── .keep
    ├── 30-Resources
    │   ├── .keep
    │   └── Google Antigravity Documentation.md
    ├── 40-Archive
    │   └── .keep
    ├── 99-Meta
    │   └── Templates
    │       ├── Base_Template.md
    │       ├── Project_Template.md
    │       └── Resource_Template.md
    └── Clippings

TL;DR

• AGY WIKI OKF: Organizes your information (context) , AGY CLI commands, skills  behaviors, and A2A workflows into a token-efficient, shareable format that reduces inference costs for any LLM.
• Open Knowledge Format (OKF): Provides a standardized, vendor-neutral way to share context (Markdown + YAML), preventing platform lock-in and eliminating data fragmentation.

AGY Builders, I genuinely want your input on this. Please comment, grill me, roast me, ask questions, or give me your raw feedback on this AGY WIKI OKF setup. We are building the foundation to organize and share our data in the BYOD era. Let's build the future together.

Hey everyone!
I'd like to share a project I've been working on, it's called Orin and it's a coding agent.

I use coding agents constantly, and at some point I realized I had basically no idea what was happening between me hitting enter and code showing up.

Also I was tired of building apps I wasn't able to really debug because I didn't know how they were being built in the first place so I got busy studying: read a bunch of articles, still felt like a black box, so I just tried to build one.

Couple things worth saying before anyone digs in:

It's mostly AI-written code, no point in hiding that, but I don't think "written by AI" and "sloppy" have to go together.

I try to run all my projects in the most professional way I know of, following actual SDLC practices: spec first, then an issue, then the implementation, then a real PR review before anything merges, not vibe-coding where you just accept every diff.

Whether that shows in the actual code is for other people to judge, not me.

Also this isn't some original idea I came up with: I cloned and read through pi.dev, nanocoder, and opencode as primary references (and skimmed Cline/Kilo Code for patterns), and basically tried to take what made sense to me from each and put it into one implementation.

My whole idea was try and build something that took the best from each to make a coding agent that would perform well. I plan to benchmark it on SWE-bench Verified sooner or later, but I don't think it's ready just yet: there are rough edges and bugs, but its usable.

Some of the actual implementation stuff, for anyone who cares about those rather than the pitch:

• The loop is just: stream a response from the provider, push it to message history, if there are tool calls run them, push the results back, repeat until there's nothing left to call.
• The loop is completely headless — it doesn't touch the terminal, it just emits events. The TUI (SolidJS on top of OpenTUI, just like opencode) is a separate subscriber to those events. You could swap in a totally different frontend without touching the loop at all.
• Another thing I got from OpenCode are edits: they go through a fuzzy replacer chain, not a single exact string match — if the model's oldText is off by whitespace or indentation, it falls through a chain of matchers before giving up. I had never thought about this and can confirm it's the kind of thing you don't appreciate until you actually try to implement it.
• There's a model routing mechanism that switches different models based on what the agent has to do:
  • explore runs on a cheap/fast model by default,
  • implement on a code-tuned model,
  • review on the main model.
• Another thing I borrowed from the web is a delegate_read tool that lets the main agent hand off read-heavy grunt work (scanning a big file, summarizing logs) to a cheap model so that content never bloats the main context.
  • It's basically a one off LLM call that only returns a distilled summary, seems dumb but works surprisingly well with capable models like Claude who know exactly what to look for and delegate super well to other agents.
• Tool selection isn't a static allow-list. Every turn runs a BM25 retrieval pass over the full tool catalog (including MCP tools) via a super cool library called Ratel, so the model only ever sees the tools relevant to what it's doing in that specific turn instead of the whole catalog every time. There's even an A/B flag to compare tool_pool=ratel vs tool_pool=default in your own telemetry to see if it even makes a difference (similar to how rtk gain works).
• Every file write gets snapshotted into a shadow git history before it happens, including stuff done through raw bash — allowing the agent to have a proper /undo /redo command.
• When I implemented subagents I wanted to explore different isolation mechanisms and ended up with 3 different ones you can configure yourself:
  • shared (edits land on the main working tree, safe because they run serially),
  • worktree (isolated branch)
  • sandbox (a real E2B cloud VM, edits get thrown away on dispose — for code you don't trust at all).
  • The lead model can escalate isolation for a given task but never go below the configured floor.
• I implemented hooks borrowing from nanocoder and opencode. This allows the agent to be expanded by third party code and I bundled some sensible defaults:
  • there's a before_tool hook that rewrites bash commands through rtk so that command output gets compressed before it ever reaches the model.
• In my daily work I build AI agents and vibe coded internal tools for my company and after a while I saw how much telemetry is crucial for debugging and actually understanding agent behaviour, so I decided that my agent would ship native OTLP tracing by default.
  • This means that by adding just one environment variable you can see full traces in your telemetry platform (Langfuse, Tempo, Jaeger, whatever you like) out of the box.
• Orin is also provider-agnostic (currently supports OpenRouter, OpenAI, Anthropic, OpenCode Go/Zen and Regolo if you want an EU-hosted option) — switching provider or model happens at runtime through a provider registry, no restart needed.

None of this is groundbreaking, it's just what I landed on after reading other people's code and deciding what to keep.

Try it:

git clone https://github.com/thetombrider/coding_agent.git

cd coding_agent

./install.sh

orin

There's also a deepwiki writeup if you want the architecture without reading source: https://deepwiki.com/thetombrider/coding_agent

I would really appreciate feedback in any shape or form. I'm learning and sharing my journey, hope it helps someone.

If you vibe-code agents that browse, they probably die at Cloudflare. I open-sourced (BSD-3-Clause) a Chromium fork that fixes that. It corrects the fingerprint in native C++, not injected JS, so it holds up across iframes and workers. Real Chromium on raw CDP, drops into Playwright.

pip install tilion-fortress

Clears CreepJS and Sannysoft in my tests. Does nothing for your IP though.

github.com/tiliondev/fortress

What keeps hitting bot walls for you?

I kept copying the same rule files into every Cursor project. Built a package manager to fix it

debug-agent.md, code-reviewer.md - same files, every time, manually.

So I built something to fix that.

pip install skillhub-ai

skillhub install debug-agent

What I found after using it for a few weeks: the value isn't just

convenience. It's consistency. When I install a skill, my Claude

agent follows the same methodology on every project - same debug

discipline, same review axes, same output format. No drift.

The thing I didn't expect to build but ended up loving: compose.

skillhub compose python-patterns security-review api-design -o fastapi-expert

It merges multiple skills into one with conflict detection. Now I

have a single /fastapi-expert command that covers Python conventions,

OWASP checks, and REST design together.

22 skills in the registry. New in v0.1.2: skillhub init my-skill

to scaffold your own. It also writes .claude/skills.json on install

so your agent can route intent without loading every skill file.

It also happens to support Cursor, Codex, and Gemini - same install

command drops the file in the right place for each. But I built it

primarily for Claude Code so that's where it's most tested.

GitHub: github.com/chandrudp29/skillhub

Docs + cookbook: github.com/chandrudp29/skillhub/blob/main/docs/cookbook.md

Happy to answer questions. What skill would be most useful to you?

That question from Satya Nadella in the attached clip immediately caught my attention.

Not because it gave me the idea.

Because during my last semester, I was already running into the same problem while experimenting with AI agents.

The first demos were exciting.

But the first time an agent could call APIs, update records, send emails, or trigger workflows, the conversation changed completely.

It wasn't about model intelligence anymore.

It was about trust.

What is this agent actually allowed to do?

Who approved this action?

If something changes tomorrow, does yesterday's approval still hold?

Six months later, can anyone explain why an agent was allowed to perform a particular action?

I assumed there was already a standard way to solve this.

There wasn't.

So instead of guessing, I started talking to people.

Over the last month, I spoke with 30+ engineers, developers, and founders building AI products.

Despite working on completely different products, almost everyone described the same problems.

The approval lacked context.

The audit trail was an afterthought.

Permissions drifted.

State changed before execution.

Every team was quietly building its own control layer around AI agents.

That realization is what led me to build Duct.

Duct sits between your product and its callers—human or AI. A single manifest defines what actions exist, which are agent-accessible, which require approval, and every action executes with scoped permissions, explicit versioning, and a complete audit trail.

Every company can build this themselves.

Just like every company can build authentication or integrate directly with payment processors.

Yet most products choose Sign in with Google, Auth0, or Stripe—not because building v1 is impossible, but because maintaining identity, security, compliance, edge cases, and reliability eventually becomes a product of its own.

I believe AI governance is heading down the same path.

The question isn't whether engineering teams can build an AI control layer.

It's whether, five years from now, they'll still want to.