Krishna Tej Hubli

AI-assisted financial review with strict data boundaries

A financial review needs to explain changing portfolio and cash-flow data without sending raw workbooks or account identifiers to a model provider.

• The model receives a small, structured metrics and alerts payload. Raw workbooks, account identifiers, object-storage links and unfiltered text do not cross the API boundary.
• Uploaded workbooks are parsed in memory and never persisted as files. Routes are protected, queries are parameterized, requests are validated, and deterministic calculations remain the source of truth.
• The AI response uses a structured contract. Observations must refer to supplied metric identifiers, and unusable model output is rejected.

• Cloudflare Worker and D1
• In-memory workbook parsing, no file storage
• Minimal structured model input
• Structured response validation

TakeawayFor sensitive data, the API boundary and validation rules matter as much as the prompt.

LLM-assisted discovery, matching and operational visibility

Job discovery should reduce manual review without trusting a title match or a single model score to decide whether an opportunity fits.

• Axia evolved through Job Hunter Agent and Yogya stages. It filters by title, recency and location before model use, then routes candidates through low-cost triage and a structured deep evaluation.
• The pipeline uses a sanitized candidate profile, versioned cache entries, prompt and response audit records, and repair handling for malformed JSON.
• Yogya ingests run results through an authenticated endpoint, persists operational history in D1 and R2, and shows job, score and run trends in a private dashboard.

• Workday, SmartRecruiters and Greenhouse
• Two-stage LLM routing
• SQLite cache and audit records
• Cloudflare D1 and R2 operations dashboard

TakeawayA useful model score needs deterministic filters, evidence and an operational trail.

Bounded model judgment for a high-risk execution flow

A model that can influence a leveraged financial transaction must not have authority to choose the instrument, side, leverage, price or arbitrary order size.

• The model is constrained to a typed allow, skip, reduce, close or escalate decision. It has no exchange tools and cannot choose any order detail.
• A deterministic risk layer validates fixed-point sizing, exposure and leverage caps, signal freshness, idempotency, position reconciliation and a kill switch.
• The rollout design starts with a rules-only baseline, then uses shadow-mode evaluation and a confidence threshold. Failure and low confidence resolve to skip and alert.

• Typed decision contract
• Deterministic risk authority
• Durable audit records
• Shadow-mode rollout plan

TakeawayFor high-risk automation, the model should advise within strict bounds while code holds final authority.

Reusable operating model for multi-agent software delivery

Multi-agent development needs clear ownership, quality gates and deliberate model selection, or it becomes costly and difficult to review.

• The template separates orchestration, architecture, review, implementation, testing and product design responsibilities.
• Model choice is configured in one place, so changing a model does not change an agent's instruction set or role.
• Each project keeps its domain requirements, architecture and data separate from the reusable delivery process.

• Orchestrator plus seven hidden specialists
• Central model configuration by tier
• Project-specific context kept separate
• Architecture and review gates
• Automated claim verification, 21 checks
• MIT licensed

TakeawayGood multi-agent work depends on explicit ownership and review, not more agents.