.png&w=256&q=75)
Marco Antonio Ga@e8-aura
3
Events attended
2
Submissions made
Singapore
1 year of experience
About me
Engineer and builder focused on practical AI for manufacturing. I am interested in using agents, automation, local AI, and intelligent workflows to reduce repetitive work and create more autonomous industrial systems. I also have a strong interest in knowledge-sharing, training, and making complex technical ideas easier to understand. I see AI not only as an automation tool, but as a cognitive partner that can help people learn, reason, solve problems, and make better decisions. My goal is to build useful AI systems that improve both how work gets done and how knowledge is created and shared.
🤓 Latest Submissions
ResponseCompass: Context-Aware Responder Dispatch
When equipment fails on a factory floor, the closest available technician is often not the best person to send. ResponseCompass is a context-aware dispatch agent inside a persistent, simulated control room. It finds who should respond to each issue right now, and explains why. Application code establishes the evidence: the simulation clock, each responder's location, shift and workload, eligibility, past resolution history, and two transparent baselines (nearest responder and a naive score). Compass, running on AMD Token Factory (MiMo-V2.6-Flash by default), then ranks only the eligible candidates it is given and writes a qualitative rationale. A second model acts as an event planner that proposes realistic incidents. Every model output is validated; if it is slow, rate-limited or invalid, the system falls back to a deterministic path, so dispatch never stops. Offers go out automatically. Responders accept or reject asynchronously, complex jobs pull in a second responder, and central command can override at any time. Each decision keeps a full audit trail, and the event feed flags where Compass disagreed with the baselines. Each responder's true skill is hidden simulation truth that no model ever sees, so outcomes reflect real fit rather than anything the model was told. Operators get a live floor map, issue and responder views, and day, week and month analytics on resolution time, success and downtime. Provider controls (rate limiting, 429 retries, a circuit breaker) keep usage within AMD's limits, and an API-free Offline mode makes the demo reproducible. Built with Node.js, plain JavaScript and a 270+ test suite including Chromium end-to-end tests.
18 Oct 2026
Stickler - Rules That Stick for Bob
Teams write rules for coding agents in prose: .bob/rules/, AGENTS.md, CONTRIBUTING.md. Agents do not reliably follow them; a publicly reported IBM Bob case (IBM/ibm-bob#247) shows exactly this failure mode. Prose does not bind. Stickler is an IBM Bob custom mode paired with a small, fixed, standard-library-only Python engine. Bob reads a project's own rule documents and splits them into atomic rules, giving each one exactly one bucket: Block (a supported check kind expresses the rule exactly, and at least one tool route can refuse it before the tool runs), Audit (checkable only afterward, from final file state), or Judgment (no supported check kind expresses it exactly — flagged as needing a human, or as mechanically unsupported by this engine). Block and Audit rules become declarative JSON specs with generated test cases; a deterministic offline engine (no LLM, no network, standard library only) evaluates them at Bob's PreToolUse and Stop hook events, blocking disallowed tool calls before they execute and auditing final state for what can only be caught after the fact. Then Stickler measures itself against five falsifiable hypotheses: what share of rules is mechanically checkable at all; how well Bob's extraction and classification match a human-reviewed reference set frozen in advance; whether Bob's own generated specs pass Bob's own generated tests; whether those specs give correct whole-policy verdicts on independent test cases Bob never saw; and, in live sessions, whether the hook actually prevented observed rule-violating tool calls without wrongly blocking allowed ones. Every result is published as supported, not supported, or inconclusive — never rounded up. The strongest claim Stickler ever makes about a rule is "validated for the tested routes," never "enforced," and audit findings are always called detection, not prevention. Target users are teams and platform engineers running Bob at scale who want their prose rules to have a testable, falsifiable relationship to what the agent actually does — not just a document they hope gets read. The enterprise path is Bob 2.1's EnforcedHooks admin policy, which can lock Stickler's hook in place organization-wide; this is described in the design but intentionally out of scope to build or test in v1. What makes this different from existing guard-hook or rule-distribution tools is that none of them start from a team's own prose and do all three things at once: use a model to split and classify the rules, compile the checkable ones into tested runtime checks, and openly state which rules cannot be checked at all — then publish the accuracy of that whole pipeline against a reference standard, favorable or not.
27 Sep 2026
