Architecture, independent due diligence, competency analysis, career record, and what hiring me actually buys. Every claim here is either measured, externally reviewed, or scoped down to what I can defend.
NINA is a personal, local-first autonomous AI infrastructure: a multi-agent orchestration system I designed, built and operate independently, built to run continuously on consumer hardware under strict resource constraints. Commands enter over Telegram, pass through a sanitisation gateway, and reach build and audit engines behind a governance layer. Inference is tiered and cost-aware, preferring local and low-cost paths before anything paid. Every change is a governed transaction rather than a blind edit.
NINA is not a product, not for sale, and not production-grade. She is a personal capability project under active development. What she proves is one thing, and proves it well: that I can research, design, build and govern working AI systems with my own hands. The long-form story is here; the dated development log is in the updates repository.
The governance layer is the differentiator the market is paying for. Stripe's public AI Security role describes building inference-path security tooling: defenses against prompt injection, jailbreaks, and tool misuse. Notion's custom-agent architecture starts with zero permissions, layered prompt-injection mitigations, runtime monitoring, and mandatory confirmation for risky actions. NINA's governance gatekeeper, compliance scoring, and constitutional laws are the same control pattern, built independently and already running.
| Company | Public evidence |
|---|---|
| Stripe | Inference-path security — defends against prompt injection, jailbreaks, tool misuse; separate SGRC role covers ISO 27001, PCI DSS, SOX, NIST control evidence. |
| Brex | Policy-enforcing agents — auto-approves low-risk cases, escalates by risk level, monitors spend continuously. |
| Adyen | Agentic commerce control — explicit mandates, tokenization, SCA compliance, fraud prevention. |
| Notion | Zero-permission runtimes — least privilege, layered defenses, mandatory confirmation gates. |
Four verifiable signals, none of them self-reported claims — each pulled live from the repository or a third party.
Shown openly, including what isn't finished — the honest-scoping discipline applied to the repository itself.
Local models preferred before low-cost external, before paid fallback — continuously re-evaluated, not configured once. Full token/time/throughput/intelligence breakdown in the architecture doc.
An independent technical review of the repository found a local-first, continuously-running autonomous AI system built and maintained by a single owner-operator, using a workflow that combines human-directed architecture with AI-assisted implementation — with sustained, high-frequency engineering activity over an extended period and a large, actively maintained backlog of fully specified work.
The review named governance-as-code as the system's defining trait: a defined precedence among competing engineering priorities embedded directly into operating rules, with safety and data protection treated as non-negotiable constraints. Distinct execution components carry different trust and permission levels, and sensitive information is handled through a dedicated component under stricter isolation.
| Architectural concern | Typical cloud-AI approach | This system's approach |
|---|---|---|
| Compute location | Centralised, cloud-first | Local-first with cloud fallback |
| Resource selection | Static, configured once | Dynamic, continuously re-evaluated |
| Failure handling | Basic retry logic | Layered software and physical safeguards |
| Permission model | Often uniform access | Differentiated trust levels by component |
| Change governance | Automated tests, sometimes human review | Embedded priority policy plus explicit boundaries |
"Some foundational subsystems were still under active development at time of review. The system should be described as actively maturing, not fully production-hardened."
SWIFT operator since 2009, administrator since 2024. Alliance Access/Web administration and migration, CBPR+ ISO 20022 (coordinator and internal trainer), CSP compliance, sanctions screening, FATCA/IDES, RMA & GPI, ASYCUDA, EDF, correspondent banking.
Lead Auditor, ISO/IEC 27001:2022 (ISMS). AIBB and JAIBB, Institute of Bankers Bangladesh. Basel III, ICRRS credit risk grading, AML/KYC, CTR/STR reporting, board-level regulatory and security memoranda.
Sixteen years across cash and general banking, credit (proposals, feasibility, recovery), foreign trade import operations, and head-office trade finance — teller counter to Board memo.
Multi-agent orchestration, LLM integration, context compression, agent-driven code synthesis, structured delegation to AI agents — practised hands-on through NINA under strict hardware limits.
Deliberate design toward minimising ongoing inference cost through tiered resource selection — local and low-cost paths before paid services — with multiple inference sources behind a common abstraction and automated selection logic.
Governance-as-code: defined precedence among competing priorities embedded in operating rules, differentiated trust levels per component, strict isolation of sensitive data, bounded automated actions.
Automated failure detection and recovery, hardware-protective safeguards including continuous thermal and resource guarding, layered software-plus-physical resilience for sustained autonomous operation.
Linux services, cron pipelines, Git/GitHub Actions, virtual runtimes, secure cloud-to-local relays, continuous background operation with automated recovery.
A separate independent analysis mapped the repository evidence to transferable professional value, concluding on a profile centred on distributed-systems thinking, AI infrastructure cost engineering, autonomous-system governance design, and structuring complex work for delegation.
| Competency | Evidence category | Transferable value |
|---|---|---|
| Multi-source AI orchestration | Coordinated use of multiple inference sources with automated selection | Organisations managing several AI vendors |
| AI cost engineering | Deliberate design toward minimising inference cost via tiering | Quantifiable cost-reduction framing |
| Reliability engineering | Automated failure detection/recovery, hardware-protective safeguards | SRE discipline in a novel domain |
| Security-conscious design | Explicit isolation of sensitive data handling | Security-first thinking for regulated industries |
| Autonomous governance | Defined precedence rules, differentiated trust levels | Maps to enterprise AI governance demand |
| Work specification at scale | Fully specified engineering tasks with explicit scope | Planning and technical communication |
| Technical debt management | Ongoing consolidation separate from feature work | Longevity-oriented engineering discipline |
Four patterns recur throughout: gating new capability behind safety and hygiene checks; a single source of truth per component; bounded automated actions; and attached verification per subsystem. Every backlog item is written like a detailed contractor brief — defined scope, required context, explicit boundaries, verifiable completion criteria — a skill the review associates with technical leadership.
"Clients and employers would not be buying NINA itself but the mind capable of repeatedly designing systems like NINA: a personality that treats AI as infrastructure governed by explicit rules, builds for resilience and auditability, and prefers deep, structured thinking over surface-level experimentation."
"Very few people combine SWIFT and ISO 27001 familiarity with autonomous AI architecture and local-first systems design in one profile. That intersection is a genuine moat."
The dated record. The same nearly seventeen years told as a story — what each posting taught me — is in the long-form profile.
Sole SWIFT administrator for the entire bank network: Alliance Access and swift.com administration, CSP execution, version and hardware migration, CBPR+ ISO 20022 implementation and internal training, FATCA/IDES, Board and central-bank reporting, FI/correspondent banking, Bangladesh Bank liaison.
Patch discipline for Alliance Access/Web with zero disruption, RMA and GPI, token management, sanctions screening, ASYCUDA and EDF.
Complex credit proposals, feasibility and working-capital assessment, Basel III and ICRRS analysis, recovery and write-off implementation, audit compliance.
Head Office credit committee and Board memoranda; validation of branch-submitted data; working-capital decision support.
Import LC operations for Bangladesh Bank, BPDB, DGDP, CMSD and GTCL — the branch's highest-value desk: bonds, credit reports, foreign supplier negotiation, document scrutiny and discrepancy handling.
Six years leading a specialised LC unit: proposals, Board and Credit Committee memoranda, correspondent banking, SWIFT RMA.
SWIFT Alliance Messenger, DC/LC operations, general banking, clearing, remittances, cash; temporary GB In-Charge and Cash In-Charge; deputations across Commercial Credit, Recovery and ICT Division.
NINA is the proof of concept, not the product. The product is a repeatable capability: I research, build, and repeat — I don't just build AI features; I engineer autonomous, governed systems that organisations can trust. An independent business-value review mapped the evidence to problems organisations actually pay to solve.
| Business problem | Evidence it can be solved | Value proposition |
|---|---|---|
| Unpredictable, rising LLM API costs | Tiered resource selection designed to minimise inference cost | "I reduce AI operating cost" |
| Over-dependence on one AI vendor | Provider-independent architecture, local-first fallback | Reduced lock-in risk |
| Ungoverned AI systems | Defined precedence rules, differentiated trust levels | "I engineer deterministic, governed AI" |
| Sensitive data exposure | Explicit isolation of sensitive data handling | Built for regulated industries |
| Slow AI-feature delivery | Structured, delegable work specification; sustained cadence | Delivery without headcount growth |
| Fragility in 24/7 AI services | Layered software and hardware resilience | Uptime engineering for continuous services |
The transferable claim is the methodology — tiering resources and selecting dynamically — applicable to any organisation watching its inference bill grow.
Directly relevant to edge deployments and data-residency-constrained clients who cannot ship their data into someone else's cloud.
Concrete, describable evidence of governance capability — increasingly demanded by enterprises and regulators alike.
A transferable management capability for organisations delegating execution to distributed or automated resources: sustained cadence without headcount growth.