AI Engineering · Project-Based Training

AI Agents and Tool Integration

Proposed advanced course. Enrollment remains closed until curriculum depth, delivery owner, pricing, and lab constraints are approved.

  • Python
  • Tool schemas
  • LLM APIs
  • Evaluation harness
  • Git

This is fee-based Project-Based Training — not a paid internship. Registering interest is not enrollment and does not collect payment. Fee details will be shared before enrollment.

Overview

Program facts

Duration
1 month
Level
Advanced
Weekly commitment
Approximately 10–15 hours per week (subject to final schedule)
Delivery
Online
Availability
Coming soon — interest registration available
Fee
Fee details will be shared before enrollment
Mentor / supervisor
Instructor or delivery owner assigned before open enrollment.
Delivery owner
Assigned before enrollment opens
Certificate policy
Certificate policy confirmed at enrollment open.
Fit

Audience, prerequisites, and selection

Audience

  • Engineers who already build LLM features

Prerequisites

  • Prior LLM application experience
  • Solid programming and Git skills
Curriculum

Curriculum

Curriculum status: forthcoming / proposed. Topics below are indicative and not a finalized enrollment curriculum until marked approved.

  • Tool schemas and validationadvanced
  • Bounded agent loopsadvanced
  • Observability and evaluationadvanced
  • Security boundaries for toolsadvanced
Outcomes

Learning outcomes

  • Implement a bounded tool-using workflow with tests
  • Document safety constraints and failure handling
Project

Project specification

Build a tool-integrated assistant with explicit allowlists, bounded loops, and evaluation cases.

Problem statement · Illustrative
A user needs an assistant that can call a small set of approved tools safely, without unrestricted side effects.
Primary user workflow · Illustrative
Receive a request → validate intent → call an allowlisted tool if needed → return a structured result or a safe refusal.
Functional scope · Illustrative
Tool schemas, bounded agent loop, allowlist enforcement, observability of tool calls, and evaluation cases for multi-step behavior.
Technical components · Illustrative
Application entrypoint, tool registry, validation layer, model or planner call, logging, and evaluation harness.
Data requirements · Illustrative
Synthetic or sample tool payloads only. No production customer systems unless an open cohort explicitly states otherwise.
Testing expectations · Illustrative
Happy-path tool call, disallowed tool refusal, and at least one malformed tool response or timeout case.
Known limitations · Illustrative
Not an autonomous multi-agent platform. Unbounded browsing, arbitrary code execution, and production tool access are out of scope.
What counts as completion · Illustrative
Working bounded workflow, safety notes, evaluation cases, and a demonstration explaining tool boundaries.

Examples

  • Tool-integrated assistant with explicit allowlists and evaluation cases

Deliverables

  • Working bounded tool workflow
  • Allowlist and safety notes
  • Evaluation cases for success and refusal paths

Example or assigned project work—not a published student achievement or employment guarantee. Student work is not assumed for commercial use without appropriate agreements. Sections marked illustrative are representative examples, not a fixed commercial brief.

Assessment

Evaluation criteria

How work is reviewed — clarity of decisions matters as much as a working MVP.

  • Project rubric focused on safety and reliability

Evaluation focuses on observable engineering evidence. Exact rubrics are published per program when approved.

  • 01

    Main workflow correctness

    Does the primary user journey work as specified?

  • 02

    Code comprehension

    Can the participant explain what the code does and why?

  • 03

    Architecture explanation

    Are component boundaries and trade-offs articulated clearly?

  • 04

    Input validation

    Are invalid inputs rejected or handled safely?

  • 05

    Testing

    Are expected behavior and at least one failure mode checked?

  • 06

    Edge-case handling

    Does the work account for realistic non-happy-path conditions?

  • 07

    Documentation

    Can another engineer set up, run, and understand the MVP?

  • 08

    Demonstration

    Is the working result shown with an honest account of limitations?

Frequently asked questions

Vasiva Academy

Ready to build something real?

Choose a pathway, review a program, and register interest when enrollment opens.