Dilan Dilruksha — Software Engineer in Colombo, Sri Lanka

Agent CLIs are trusted with real filesystems and real shells, but many of them let the model decide what is safe to run. When authorization lives in the prompt, a single bad tool call can overwrite files or execute a destructive command — and there is usually no durable record of what happened or why it was allowed.

• Authorization must live in deterministic code, never in the model's judgment.
• Side effects require explicit human approval before anything executes.
• The agent must never escape its workspace — no absolute paths, no symlink escapes.
• Runs and their rationale must be persistable and resumable, not ephemeral transcripts.
• Every layer must stay swappable so the runtime is not tied to one model vendor.

1. 01
   Authorization as a property of the runtime, not the prompt.

   A strict event-driven turn loop — model, validate, policy, approval, execute, persist — forces every side effect through the same checks in the same order, so a tool call that was never approved cannot slip past.

2. 02
   Zod-validated tools as a security boundary.

   Inputs are schema-validated before execution, so a malformed or hallucinated tool call is rejected at the boundary instead of reaching the filesystem or shell.

3. 03
   Workspace-scoped filesystem tools.

   read_file, write_file, and friends are confined to the workspace, deny symlink escapes, and stale-check files before overwriting so a concurrent edit is not clobbered.

4. 04
   A guarded shell with bounded blast radius.

   The shell tool enforces timeouts, output caps, cancellation, and process-group cleanup — a runaway command cannot outlive the turn that started it.

5. 05
   SQLite sessions that survive the terminal.

   Node's built-in node:sqlite persists sessions to ~/.parallax/sessions.sqlite, so work can be listed and resumed later instead of dying with the process.

6. 06
   ModelProvider as a seam, not a dependency.

   Providers are swap-in implementations — a scripted fake for demos and tests, and an OpenAI-compatible provider for NVIDIA NIM or any endpoint you repoint the base URL at — keeping the runtime vendor-neutral.

• v0.1 beta live as a working single-agent loop, published on npm.
• Every side effect requires explicit human approval, with diff previews before edits.
• ALLOW / ASK / DENY policy resolved by code, with read-only and workspace modes.
• Invalid tool calls are rejected at the boundary by Zod validation.
• Durable SQLite sessions with list and resume flows.
• Architectural import boundaries enforced by ESLint so policy cannot be bypassed.
• A macOS desktop app and an iOS companion app in progress.

Traditional flood irrigation in Sri Lankan irrigation schemes (like Udawalawe) operates on fixed manual schedules, leading to low water use efficiency (30-50%). Smallholder farmers lack real-time telemetry or crop health monitoring, while dam operators cannot dynamically plan land and water allocation when weather forecasts or market prices shift mid-season.

• Must enforce strict regional water quotas allocated by the Irrigation Department before each season.
• Decoupled microservices must integrate resiliently without crashing if satellite or forecasting APIs fail.
• Model inference latency (large 2.6GB Random Forest model) must not block real-time dashboard responsiveness.
• Optimization must balance economic profitability with national paddy cultivation policy mandates.

1. 01
   Fuzzy-TOPSIS multi-criteria suitability logic.

   Ranks 30 crop candidates per field boundary by modeling input parameter uncertainty (soil pH, conductivity, slope, and size) with trapezoidal fuzzy numbers to prevent unviable recommendations.

2. 02
   LightGBM regressor with a 24-feature price pipeline.

   Predicts harvest-time crop prices by combining temporal seasonal monsoons (Yala/Maha), growing degree days (GDD), and price volatility lags, classifying risk indices for decision support.

3. 03
   Mixed-Integer Linear Programming via PuLP/Pyomo.

   Solves the constrained optimization problem to maximize regional profits subject to seasonal water quotas, paddy conservation rules, and administrator risk tolerance bounds.

4. 04
   Adaptive 'Plan B' re-planning middleware.

   Calculates an optimized crop adjustment roadmap mid-season if water quotas drop or market prices collapse, minimizing transition costs and protecting farmers from complete yield loss.

• 20–35% water savings achieved by connecting imminent weather predictions directly to smart valve closures.
• 8–14% expected farmer profit gain per hectare compared to historical officer-planned allocations.
• 100% feasibility under allocated reservoir quotas checked via the PuLP/Pyomo optimization constraints.
• Response latency reduced below 80ms by loading Random Forest weights into system memory once during FastAPI startup and caching lookups using Redis.
• Integrated cross-service API contracts with freshness and staleness metadata to degrade gracefully during network failures.

Small businesses were juggling WhatsApp, Instagram, email, customer records, product catalogs, payment proof, bookings, and follow-ups across disconnected tools. Owners needed visibility, staff needed shared context, and customers needed faster responses across every channel.

• Tenant-scoped access across inboxes, contacts, orders, bookings, websites, billing, analytics, and platform-admin workflows.
• Messaging and webhooks need background reliability without slowing dashboard requests.
• Website builder publishing must avoid leaking draft tenant data into public pages.
• AI concierge flows need memory, retrieval, and intent routing without taking over normal staff workflows.

1. 01
   FastAPI control plane with tenant-aware dependencies.

   Authentication, membership checks, plan limits, and RBAC happen in backend dependencies and service layers, so tenant boundaries do not depend on UI discipline or request-body trust.

2. 02
   Redis and Celery for work that should not block users.

   Messaging, appointment, subscription, AI, Instagram, WhatsApp, notification, and system jobs run through workers. The dashboard stays responsive while long-running operations are retried out of band.

3. 03
   Publish records for public websites.

   Website builder drafts can move into explicit publish manifests, so public pages read stable website, product, service, booking, and inquiry data instead of mutable dashboard state.

4. 04
   AI concierge as specialist agents behind a supervisor.

   Retrieval, memory, and specialist routes let the system answer product, order, booking, and reservation intents while preserving a clear path back to human staff workflows.

• Live at nomirashop.online.
• Omnichannel inbox foundation across WhatsApp, Instagram, and email.
• CRM, catalog, checkout, orders, invoices, payment proof, bookings, and reservations share one tenant model.
• Website builder and publish records support public tenant sites, product/service pages, booking pages, and inquiries.
• AI concierge foundations include embeddings, retrieval, memory, and intent routing.
• Dashboard analytics summarize sales, orders, customers, payments, campaigns, bookings, communication, team activity, top products, and recent orders.

Tuition institutes were running operations across spreadsheets, payment receipts, chat groups, and physical attendance sheets. They needed a single platform that owners, tutors, students, finance, and admissions could share — without leaking one institute's data into another's.

• Tenant isolation across seven distinct user roles.
• Financial flows must stay auditable end-to-end — fees, ledgers, outstanding balances, receipts.
• Mixed-trust surfaces — a public marketplace sitting alongside private tenant data.
• One codebase, one deployment, many tenants.

1. 01
   Tenant identifier on every record.

   Role-based access enforced at the query layer through Prisma — not in the UI — so a misrouted page never becomes a data leak.

2. 02
   pnpm monorepo for a unified workspace.

   Front-end, server, and shared types live together. A permission change in one place propagates as a single, reviewable PR.

3. 03
   Receipt upload + super-admin approval.

   Tenants upload payment receipts; a super admin gates activation. A human checkpoint replaces auto-billing while the platform is still finding its shape.

4. 04
   QR attendance on the same data plane as the community feed.

   Students scan in once. Tutors, parents, and admissions all read the same record — no separate notification pipeline to keep in sync.

• Live at gurulink.online.
• Supports 7 user roles with tenant-isolated data.
• Seven role surfaces served from a single deployment.
• Fee → ledger → outstanding → receipt covered end-to-end.
• QR attendance, subscription approval, fee tracking, and public marketplace flows are covered.