Martin Wong

Founder, Binary Elements. Building AI agents that act inside real systems, with a named human approving what matters. Melbourne.

[Martin Wong @bemartinwong]

I'm Martin, founder of Binary Elements.

We build AI agents that work in live systems: SAP, IT fleets, business SMS.

Biggest lesson: the approval gate is what lets agents move fast. Clear owner, clear boundary, and the agent can do far more.

Posting what we learn as we build.

[Martin Wong @bemartinwong]

@mika_systems Rough lesson, and glad it got caught. I now run third-party MCP servers with their own minimal env, never my main shell's. It takes a minute to set up and means a bad server only sees what I chose to give it.

[Martin Wong @bemartinwong]

@kman62 Exactly. It wasn't a bug, it was the agent trusting its working folder. The change that helped me most was deciding which instruction files count before the agent starts, so it can move fast inside a folder I've already vouched for.

[Martin Wong @bemartinwong]

@Kipnis_a Agree the risk section is the useful read. As a builder my takeaway is practical: scoped credentials and a log per action aren't overhead, they're what lets me hand agents bigger tasks without rereading everything they touched.

[Martin Wong @bemartinwong]

@stretchcloud Handing an agent the real screen is fast to build, but it also means it can tap anything I can. What has worked for me is pairing screen access with a short list of actions that need my OK first. That keeps it fast on the boring 90%.

[Martin Wong @bemartinwong]

@ZainManji Ticket to verified PR is the one I see pay off fastest, mostly because "verified" forces a clear owner and a test that has to pass before a human looks. Of these, which one breaks first when a team skips naming who approves the merge?

[Martin Wong @bemartinwong]

@Joe_brendan_ Seeing this in my own work. When a working screen takes minutes, the slow part becomes agreeing what "done" looks like. I now write the acceptance check first, let the agent build against it, and only open the design file once the check passes.

[Martin Wong @bemartinwong]

@Nonosam2 I do a version of this. Cross-review catches more than self-review, but what made it work was giving both agents the same written spec to check against. Without that they just argue style. With it, I review the disagreements, not every line.

[Martin Wong @bemartinwong]

@BenjieMalinao Same call I made. The prompt-level "are you sure" is nice UX, but the server check is the one that holds. Once the refund rule lives in my backend, I can let the agent run longer jobs without watching it. Do you key retries on the job ID or the action itself?

[Martin Wong @bemartinwong]

@DecentralisedA "Weaken their own monitoring" is the one I'd put first. An agent should never be able to change the logs or alerts that watch it. Keep that out of reach and most of the other failures on the list become things you can see and fix quickly.

[Martin Wong @bemartinwong]

@_odsc That question shapes everything downstream. I give agents a sandbox with throwaway credentials and full freedom inside it, plus a short list of things that leave the sandbox. Clear limits are what let me hand over bigger jobs, not smaller ones.

[Martin Wong @bemartinwong]

@bdescalo Employee-built apps are the new shadow IT, just faster. What worked for us is treating each one like a small product: a named owner, a list of the data it touches, and an easy way to retire it. Who owns an app there once its builder changes roles?

[Martin Wong @bemartinwong]

@inorbit01 @github Good to see supervising and governing in the syllabus, not just building. The skill that matters most in practice is scoping: what an agent can change on its own and what needs evidence attached before it ships. Get that right and agents run much longer unattended.

[Martin Wong @bemartinwong]

@nurhayatdev The fix I like is boring: agents only start inside a project folder with a known git history, never in Downloads or home. That one habit removes a whole class of surprises. Has anyone made their agent CLI refuse to start outside a repo?

[Martin Wong @bemartinwong]

@m4ttbuilds I do now. The rule I landed on: an instruction file only counts if it came in through a reviewed commit. Anything else in the working folder is just text. It costs nothing day to day and lets me point agents at bigger tasks.

[Martin Wong @bemartinwong]

@Sumanth_077 Handoffs are where multi-agent setups get interesting. What makes them work for me is a written record of who picked up what and why, so when two agents touch the same file I can see the trail instead of guessing which one made the call.

[Martin Wong @bemartinwong]

@edinsoncode Agree. The tool I stayed with mattered less than the repo it lands in. Once I had a short task spec and tests that fail loudly, both agents got faster, because I stopped rereading every diff and started checking it against the spec instead.

[Martin Wong @bemartinwong]

@mdnadeemai Splitting builder and reviewer across models is the part I'd copy. The reviewer only has to say yes or no against the plan, which is cheaper and easier to trust than one model grading its own work.

[Martin Wong @bemartinwong]

@MrDutch310822 Underrated habit. The "folders to leave alone" line does more for me than any prompt tweak. It turns a judgment call into a rule, so I can hand the agent bigger tasks without watching every step.

[Martin Wong @bemartinwong]

@choblin29 This is why I treat instruction files like code, not notes. If a file in the working folder can steer the agent, it should come from a repo someone reviewed. Does your setup refuse to run when it finds an AGENTS.md it didn't expect?

[Martin Wong @bemartinwong]

@stretchcloud Long-running tasks change the approval question too. When a tool call can run for an hour, I want the scope agreed before it starts and a clear record of what it touched when it ends, not a prompt halfway through that nobody is awake to answer.