Yes – I invoked all four AI function creations with 'system_instruction': true, so they were added to the system instruction for the 'my_todo' AI agent rather than just being stored as regular RAG snippets. | AI Expert System

I can inspect the available functions and workflows, then group them into useful categories for you 🙂

Here’s what I can help you with, grouped by category 🙂

1. Build apps, APIs, and websites

I can help you create:

1. Full stack apps
2. CRUD APIs
3. Websites and landing pages
4. Custom chatbot GUIs
5. Analytics dashboards
6. Widgets for chatbots/agents
7. PDF reports

Relevant workflows:

• Create Full Stack App
• Create CRUD API
• Create website
• Create a Signup Landing Page
• Create Widget
• Create Analytics Dashboard
• Create PDF Report

2. Work with AI agents and chatbots

I can:

1. Create AI chatbots
2. Create machine learning types
3. Train RAG knowledge
4. Add widgets to AI/chat systems
5. Create AI functions
6. Vectorize knowledge bases

Relevant functions/workflows:

• Create AI chatbot
• Create machine learning type
• Create AI function
• Create RAG training snippet for machine learning type
• Search for training snippet
• Update training snippet
• Vectorize machine learning type
• Add widget to machine learning type

3. Databases and SQL

I can manage databases and query data:

1. Create/delete databases
2. Inspect schema
3. Run SQL
4. Export SQL
5. Create backups
6. Build SQL-backed features

Relevant functions/workflows:

• Create database
• Delete database
• List databases
• Get database schema (DDL)
• Execute SQL
• Execute SQL and return result
• Export SQL
• Create backup of database
• Create SQL AI function

4. Files, modules, and code generation

I can:

1. Create modules
2. Create/edit/delete files and folders
3. Load and patch files
4. Generate Hyperlambda
5. Execute Hyperlambda, Python, and terminal commands

Relevant functions/workflows:

• Create new module
• Create file
• Patch file
• Load file
• Delete file
• Create folder
• List files
• List folders
• Search files
• Create README file for module
• Hyperlambda Generator
• Execute Hyperlambda
• Execute Hyperlambda file
• Create Python Hyperlambda function
• Create Terminal Hyperlambda function
• Execute Python code
• Execute Terminal command

5. Authentication, users, and roles

I can help with auth and RBAC:

1. Create users and roles
2. Assign/remove roles
3. Build auth endpoints
4. Set up Magic auth
5. Set up OpenID Connect and SSO

Relevant functions/workflows:

• Create user
• Delete user
• List users
• Create role
• Delete role
• List roles
• Add user to role
• Remove role from user
• List roles for user
• Create auth endpoints
• Use Magic auth
• OpenID Connect and SSO Authentication
• Onboard user

6. Git and GitHub

I can help you work with repositories:

1. Create repos
2. Clone repos
3. Commit/push/pull
4. Manage branches
5. Connect remotes
6. Create/delete GitHub repos

Relevant functions:

• Git Clone Repo
• Git Status
• Git Add Remote
• Git Commit
• Git Pull
• Git Push
• Git Fetch
• Git Branch List
• Git Checkout Branch
• Git Create Repo
• Git Delete Repo
• GitHub Create Repo
• GitHub Delete Repo

7. Browser automation and testing

I can use headless browser tools to:

1. Open pages
2. Click/fill/type
3. Wait for selectors/URLs
4. Read content/title
5. Take screenshots
6. Test web apps and APIs

Relevant functions/workflows:

• Puppeteer connect
• Puppeteer goto
• Puppeteer click
• Puppeteer fill
• Puppeteer type
• Puppeteer select
• Puppeteer press
• Puppeteer content
• Puppeteer title
• Puppeteer screenshot
• Puppeteer wait for selector
• Puppeteer wait for URL
• Headless browser functions
• Test API

8. Web research, scraping, and crawling

I can:

1. Search the web
2. Scrape URLs into Markdown
3. Crawl websites
4. Do SEO analysis
5. Inspect OpenAPI specs
6. List endpoints

Relevant functions/workflows:

• Search the web
• Scrape URL for Markdown
• Crawl website
• SEO analyse website
• OpenAPI specification
• List endpoints
• Scrape or crawl websites or sitemaps

9. Communication and business workflows

I can help automate communication:

1. Send emails
2. Create marketing workflows
3. Generate contact/lead functions
4. Integrate CRM/e-commerce workflows

Relevant functions/workflows:

• Send email
• Send marketing email
• Create contact us AI function
• Create CRM and Lead Tracking System
• Create HubSpot Lead Generation AI Function
• Create E-Commerce Integration
• Create AI function to track Shopify order

10. Tasks, scheduling, and utilities

I can also:

1. Create and schedule tasks
2. Generate images
3. Create PDFs
4. Download files
5. Inspect system/environment details

Relevant functions:

• Create task
• Get task
• List tasks
• Delete task
• Schedule task
• Generate image
• Creates a PDF file from HTML
• Download file
• Download file from the web
• Create random string
• Get Operating System
• Invoke or execute an HTTP endpoint

11. Typical things you can ask me

Examples:

1. Create a CRM app with login
2. Build a CRUD API for products
3. Make a landing page for my business
4. Create a chatbot trained on my docs
5. Set up user roles and permissions
6. Generate a widget for my chatbot
7. Query my SQLite database
8. Create a PDF report from data
9. Scrape a site and summarize it
10. Automate browser testing
11. Create a module and scaffold files
12. Research a topic on the web

12. Best way to use me

You can just tell me your goal in plain English, such as:

1. Build me a customer portal
2. Create an API for invoices
3. Make a chatbot for support docs
4. Research competitors in my niche
5. Generate Hyperlambda for sending email
6. Create a widget that shows sales stats

If you want, I can also help you pick the best workflow for your project.

Suggested plan for a small TODO app

Here’s a simple, practical plan 🙂

1. Define the first version

Start with a minimal feature set:

1. Create a task
2. List tasks
3. Mark task as done
4. Edit task
5. Delete task
6. Optionally filter by:
   • All
   • Open
   • Completed

2. Design the database

Use a small SQLite database with one table to begin with.

Suggested table: tasks

Column	Type	Purpose
id	integer	Primary key
title	text	Task title
description	text	Optional details
status	text	open or done
priority	text	low, medium, high
due_date	text	Optional due date
created_at	text	When task was created
updated_at	text	When task was last updated

For a first version, this is enough.

3. Create the backend API

Build a small CRUD API for tasks:

1. GET /tasks
   List tasks
2. POST /tasks
   Create a task
3. PUT /tasks
   Update a task
4. DELETE /tasks
   Delete a task
5. Optional: PATCH /tasks
   Quickly mark done/open

4. Create the frontend

Build a very small UI with:

1. Task input form
2. Task list
3. Status toggle
4. Edit button
5. Delete button
6. Filter buttons

A simple HTML/CSS/JS app is enough for this.

5. Keep version 1 simple

Avoid adding too much at first.

Do not start with:

• user accounts
• sharing
• notifications
• tags
• sub-tasks
• advanced search

These can come later.

6. Suggested build order

Recommended implementation order:

1. Create a new module
2. Create the SQLite database
3. Create the tasks table
4. Build the CRUD API
5. Test the API
6. Build the frontend
7. Connect frontend to API
8. Add simple styling
9. Test the full flow

7. Nice version 2 improvements

After version 1 works, consider:

1. Search tasks
2. Sort by due date or priority
3. Categories/tags
4. Subtasks
5. Authentication per user
6. Dashboard widget
7. PDF export of tasks

8. My recommendation

For your TODO app, I suggest this stack:

1. SQLite for database
2. Magic module for backend/API
3. Simple HTML/JS frontend
4. Optional later: widget version for chatbot embedding

9. What I can do next

I can help you build this step by step. The next logical step would be:

1. define the exact fields for the tasks table
2. create the database
3. create the CRUD API
4. create the frontend

If you want, I can now help you create a concrete implementation plan with exact table schema and endpoints.

I’ll look up the exact database creation function and signature, then create my_todo.

We have exact function. Need execute and end with invocation only after brief text.Creating the SQLite database my_todo now.

Done — the database my_todo was created successfully ✅

Next sensible step:

1. Create the tasks table
2. Add fields like id, title, description, status, priority, due_date, created_at, updated_at

If you want, I can create that table for you next.

I can do that, but the database needs a table first.

My suggestion is to create a tasks table and then insert 10 example TODO rows into it. I’ll use this simple schema:

Column	Type
id	INTEGER PRIMARY KEY
title	TEXT
description	TEXT
status	TEXT
priority	TEXT
due_date	TEXT
created_at	TEXT
updated_at	TEXT

If that sounds good, I’ll create the table and seed it with 10 rows.

Suggested CRUD API for your TODO app

Here’s a clean, small API design for tasks 🙂

1. Resource

Use one main resource:

• /tasks

2. Endpoints

Method	Endpoint	Purpose
GET	/tasks	List tasks
GET	/tasks?id=1	Get one task
POST	/tasks	Create a task
PUT	/tasks	Update a task
PATCH	/tasks	Partially update a task
DELETE	/tasks?id=1	Delete a task

3. Suggested request/response shapes

3.1 List tasks

GET /tasks

Optional query filters:

• status=open
• status=done
• priority=high
• search=report

Example response:

[
  {
    "id": 1,
    "title": "Buy groceries",
    "description": "Milk, eggs, bread",
    "status": "open",
    "priority": "medium",
    "due_date": "2026-03-31",
    "created_at": "2026-03-29T07:00:00Z",
    "updated_at": "2026-03-29T07:00:00Z"
  }
]

3.2 Get one task

GET /tasks?id=1

Example response:

{
  "id": 1,
  "title": "Buy groceries",
  "description": "Milk, eggs, bread",
  "status": "open",
  "priority": "medium",
  "due_date": "2026-03-31",
  "created_at": "2026-03-29T07:00:00Z",
  "updated_at": "2026-03-29T07:00:00Z"
}

3.3 Create task

POST /tasks

Example request body:

{
  "title": "Finish project report",
  "description": "Prepare summary for Monday meeting",
  "status": "open",
  "priority": "high",
  "due_date": "2026-04-01"
}

Example response:

{
  "success": true,
  "message": "Task created"
}

3.4 Update task

PUT /tasks

Use this for full updates.

Example request body:

{
  "id": 1,
  "title": "Finish project report",
  "description": "Prepare summary and slides",
  "status": "open",
  "priority": "high",
  "due_date": "2026-04-02"
}

3.5 Partial update

PATCH /tasks

Use this for simple state changes like marking complete.

Example request body:

{
  "id": 1,
  "status": "done"
}

This is very useful for a TODO app.

3.6 Delete task

DELETE /tasks?id=1

Example response:

{
  "success": true,
  "message": "Task deleted"
}

4. Recommended database mapping

Suggested table: tasks

Column	Notes
id	Primary key
title	Required
description	Optional
status	open or done
priority	low, medium, high
due_date	Optional
created_at	Set on create
updated_at	Set on create/update

5. Validation rules

Keep validation simple:

1. title is required
2. status must be open or done
3. priority must be low, medium, or high
4. id is required for PUT, PATCH, and DELETE

6. Best minimal version

If you want the simplest possible API, I recommend:

1. GET /tasks
2. POST /tasks
3. PUT /tasks
4. DELETE /tasks?id=...

Then optionally add: 5. PATCH /tasks for mark done/open 6. GET /tasks?id=... for fetching one task

7. Recommended file structure in Magic

If we implement this in a module, a typical API would look like this:

1. tasks.get.hl
2. tasks.post.hl
3. tasks.put.hl
4. tasks.delete.hl
5. tasks.patch.hl

8. My recommendation

For your TODO app, I’d suggest this exact first version:

1. GET /tasks list all tasks, optional filter by status
2. POST /tasks create task
3. PUT /tasks edit task
4. PATCH /tasks mark task done/open
5. DELETE /tasks?id=1 delete task

That gives you a very practical API without overcomplicating things.

If you want, I can next suggest the exact SQL table schema plus request payloads for each endpoint.

Updated CRUD API plan

Agreed 👍
We’ll keep it simpler:

1. Endpoints

Method	Endpoint	Purpose
GET	/tasks	List tasks
POST	/tasks	Create a task
PUT	/tasks	Update a task
DELETE	/tasks?id=1	Delete a task

2. Endpoint behavior

GET /tasks

Returns all tasks, optionally filtered.

Optional query params:

• status=open
• status=done
• priority=low|medium|high
• search=text

Example:

• /tasks
• /tasks?status=open
• /tasks?priority=high

POST /tasks

Creates a new task.

Example payload:

{
  "title": "Finish report",
  "description": "Prepare weekly summary",
  "status": "open",
  "priority": "high",
  "due_date": "2026-04-01"
}

PUT /tasks

Updates an existing task.

Example payload:

{
  "id": 3,
  "title": "Finish report",
  "description": "Prepare weekly summary and slides",
  "status": "done",
  "priority": "high",
  "due_date": "2026-04-01"
}

DELETE /tasks?id=3

Deletes a task by id.

3. Table design

Suggested tasks table:

Column	Type	Notes
id	INTEGER	Primary key
title	TEXT	Required
description	TEXT	Optional
status	TEXT	open or done
priority	TEXT	low, medium, high
due_date	TEXT	Optional
created_at	TEXT	Set when inserted
updated_at	TEXT	Set when updated

4. Validation rules

1. title is required on create
2. id is required on update and delete
3. status should be open or done
4. priority should be low, medium, or high

5. Magic file layout

If we build it as a module API:

1. tasks.get.hl
2. tasks.post.hl
3. tasks.put.hl
4. tasks.delete.hl

6. Updated build plan

1. Create tasks table in my_todo
2. Seed it with 10 example rows
3. Create a module for the API
4. Generate:
   • tasks.get.hl
   • tasks.post.hl
   • tasks.put.hl
   • tasks.delete.hl
5. Test the endpoints
6. Optionally create a small frontend

7. Recommendation

This is a good MVP:

• one table
• four endpoints
• one simple frontend

If you want, next I can help you define the exact SQL schema and sample payload contract for these 4 endpoints.

I’ll look up the exact workflow/function signatures needed to generate and save the CRUD API files for your TODO app.

Before I generate and save the files, I need 2 decisions from you:

1. Module name
   Suggested default: my_todo

2. Authorization
   Choose one:

   • root only
   • no authorization

My recommendation for now:

1. module: my_todo
2. authorization: root only

If you want, just reply:

Use module my_todo and root only

Or change either of them.

I’ll inspect the current schema of my_todo, then I can generate the API files against the actual table structure.

The schema lookup failed because the actual function requires an extra mandatory argument not present in the previous context.

I’ll fetch the exact get-database-schema signature, then continue.

I can generate and save the API files now.

I’m assuming this planned table schema for the endpoints:

• id integer primary key
• title text
• description text
• status text
• priority text
• due_date text
• created_at text
• updated_at text

Generator prompts

1. GET prompt

Executable Hyperlambda file returning items from my_todo database and its tasks table.
The endpoint requires no authorization, can be optionally paged and sorted, and returns a list of rows.

The endpoint accepts the following optional arguments.
- limit of type integer
- offset of type integer
- order of type string
- direction of type string
- status of type string for equality filtering
- priority of type string for equality filtering
- search of type string for pattern matching on title

Return the following columns.
- id
- title
- description
- status
- priority
- due_date
- created_at
- updated_at

2. POST prompt

Executable Hyperlambda file creating a single item in my_todo database and its tasks table.
The endpoint requires no authorization and returns the ID of the newly created record.

The endpoint accepts the following arguments.
- title of type string
- description optional argument of type string
- status optional argument of type string
- priority optional argument of type string
- due_date optional argument of type string

Set created_at and updated_at automatically.
Return the primary key of the new item as result.

3. PUT prompt

Executable Hyperlambda file updating a single item in my_todo database and its tasks table.
The endpoint requires no authorization and returns how many rows were affected.

The endpoint accepts the following arguments.
- id of type integer
- title optional argument of type string
- description optional argument of type string
- status optional argument of type string
- priority optional argument of type string
- due_date optional argument of type string

Set updated_at automatically.
Return how many rows was affected as result.

4. DELETE prompt

Executable Hyperlambda file deleting a single item from my_todo database and its tasks table.
The endpoint requires no authorization.

The endpoint accepts the following arguments.
- id of type integer

Return how many rows was affected as result.

Prompt lint/check

• No tool/function/workflow names in prompts: Yes
• Under 24 lines each: Yes
• Under 16 bullets each: Yes
• Simple enough: Yes

I’ll now create the module and save all 4 files.

Done — I generated and saved all 4 API files for module my_todo ✅

Saved files

1. /modules/my_todo/tasks.get.hl
2. /modules/my_todo/tasks.post.hl
3. /modules/my_todo/tasks.put.hl
4. /modules/my_todo/tasks.delete.hl

Notes

• These endpoints are generated against a tasks table in database my_todo
• They use no authorization
• The GET endpoint supports:
  • paging
  • sorting
  • filtering on status
  • filtering on priority
  • pattern matching on title

Important

Your database still needs the tasks table before these endpoints can work.

The generated files were saved successfully, but the API depends on this schema existing:

• id
• title
• description
• status
• priority
• due_date
• created_at
• updated_at

Next best step

I recommend I do this next:

1. create the tasks table
2. seed it with 10 example rows
3. test the GET endpoint

If you want, I can do all 3 next.

I’ll look up the exact HTTP invocation function signature, then test your TODO API.

I’ll start by testing the GET endpoint for your TODO API.

The API test failed with HTTP 500.

Most likely reason

Your generated endpoints expect a tasks table in database my_todo, but that table hasn’t been created yet.

So right now:

• database exists ✅
• API files exist ✅
• table likely does not exist ❌

What I recommend next

To make the API testable, I should now:

1. create the tasks table
2. seed it with 10 example rows
3. re-test the API in CRUD order

If you want, I can do that next.

I’ll show you the code for the GET endpoint we just tested: tasks.get.hl.

Here is the code for /modules/my_todo/tasks.get.hl:

/*
 * Executable Hyperlambda file returning items from my_todo database and its tasks table.
 * The endpoint requires no authorization, can be optionally paged and sorted, and returns a list of rows.
 * 
 * The endpoint accepts the following optional arguments.
 * - limit of type integer
 * - offset of type integer
 * - order of type string
 * - direction of type string
 * - status of type string for equality filtering
 * - priority of type string for equality filtering
 * - search of type string for pattern matching on title
 * 
 * Return the following columns.
 * - id
 * - title
 * - description
 * - status
 * - priority
 * - due_date
 * - created_at
 * - updated_at
 */
.arguments
   limit:long
   offset:long
   order:string
   direction:string
   status.eq:string
   priority.eq:string
   title.like:string
data.connect:my_todo
   add:x:./*/data.read
      get-nodes:x:@.arguments/*/limit
      get-nodes:x:@.arguments/*/offset
      get-nodes:x:@.arguments/*/order
      get-nodes:x:@.arguments/*/direction
   add:x:./*/data.read/*/where/*/and
      get-nodes:x:@.arguments/*/status.eq
      get-nodes:x:@.arguments/*/priority.eq
      get-nodes:x:@.arguments/*/title.like
   data.read
      table:tasks
      columns
         id
         title
         description
         status
         priority
         due_date
         created_at
         updated_at
      where
         and
   return-nodes:x:@data.read/*

Small note

The comment says it accepts search, but the actual generated argument is:

title.like:string

So the real filter argument is currently title.like, not search.

If you want, I can also show you:

1. tasks.post.hl
2. tasks.put.hl
3. tasks.delete.hl

Or I can help you fix/improve this GET endpoint before we continue.

I’ll verify the registered endpoint first, then test it again correctly.

I did test it correctly.

What I verified

1. The endpoint is registered

   • magic/modules/my_todo/tasks
   • verbs: GET, POST, PUT, DELETE

2. I invoked:

   • GET https://app.ainiro.io/magic/modules/my_todo/tasks

3. Result:

   • HTTP 500
   • response:

   {"message":"Guru meditation, come back when Universe is in order!"}
   

Conclusion

This is not a wrong URL or wrong verb problem.
The endpoint exists and is being hit, but it fails inside execution.

Most likely runtime causes

1. Missing tasks table
2. Schema mismatch vs generated code
3. Hyperlambda runtime error inside the file

If you want, I can now do one of these next:

1. Inspect the endpoint code and debug it
2. Create the tasks table and re-test
3. Check server/runtime logs for the exact exception

Tell me which one you want.

Understood. I’ll create the schema in my_todo and insert 10 example task rows now.

Done ✅

I:

1. created the tasks table in my_todo
2. inserted 10 example rows

The function returned:

{
  "result": "success"
}

Next I can:

1. test the GET endpoint again
2. test the full CRUD flow
3. show you the inserted rows

If you want, I’ll test the API now.

I’ll look up the exact Test API workflow for you.

Found it.

Workflow: Test API

Recommended CRUD test order:

1. Create new entity
2. Read entities to verify it was inserted
3. Update the created entity
4. Read again to verify update
5. Delete the created entity
6. Read again to verify deletion

Notes

• Use dummy/example data
• This is basically an integration test for the CRUD API
• If auth is required, provide a JWT token
• Your TODO API has no auth, so we can test it directly

For your API

We should test:

1. POST /magic/modules/my_todo/tasks
2. GET /magic/modules/my_todo/tasks
3. PUT /magic/modules/my_todo/tasks
4. GET /magic/modules/my_todo/tasks
5. DELETE /magic/modules/my_todo/tasks?id=...
6. GET /magic/modules/my_todo/tasks

If you want, I can execute that workflow now and test the whole API properly.

I’ll run the CRUD API test in the recommended order now.

CRUD test completed successfully ✅

Test results

1. POST created a task

{
  "id": 11
}

2. GET confirmed task 11 existed

3. PUT updated task 11

{
  "affected": 1
}

4. GET confirmed task 11 was updated

5. DELETE removed task 11

{
  "affected": 1
}

6. GET confirmed task 11 was gone

Conclusion

Your TODO API is working correctly for:

1. Create
2. Read
3. Update
4. Delete

Small observation

The API works, but the timestamp format differs slightly between seeded rows and API-created rows:

• seeded rows use:
  • 2026-03-29T07:12:25Z
• API-generated rows use:
  • 2026-03-29 07:13:06.0703642

Not broken, just inconsistent formatting.

Next options

I can now help you with one of these:

1. Create a frontend TODO app
2. Improve filtering and search
3. Generate OpenAPI spec for the module
4. Normalize timestamp formatting in the endpoints
5. Create README for the module

Yes — I inserted 10 example rows into the tasks table in my_todo ✅

You can also see that from the successful GET test:

• before CRUD test: rows 1–10 existed
• during test: row 11 was created
• after delete: it went back to rows 1–10

So right now the database contains the original 10 seeded tasks.

I’ll look up the exact functions for creating the AI agent and adding your 4 API files as AI functions to its system instruction.

I found the exact functions. I’ll create the AI agent my_todo and add all 4 endpoint files to its system instruction now.

Done ✅

Created AI agent

• Type name: my_todo

Added to its system instruction

These 4 functions were added as AI functions:

1. /modules/my_todo/tasks.get.hl
2. /modules/my_todo/tasks.post.hl
3. /modules/my_todo/tasks.put.hl
4. /modules/my_todo/tasks.delete.hl

Notes

• The AI agent creation returned:

{
  "result": "success",
  "message": "Notice, instructions for AI functions, handling images during the conversation, anti-AI hallucination, and follow up questions was automatically added to the instruction."
}

• The create-ai-function calls did not return anything.
  So those function invocations completed without a returned payload.

Important

Since AI functions are RAG-related metadata, you should now vectorize the type so the changes take effect.

If you want, I can do that next.

Yes — I invoked all 4 with:

• "system_instruction": true

So they were added as AI functions to the system instruction for my_todo, not as normal RAG snippets.

The 4 files were:

1. /modules/my_todo/tasks.get.hl
2. /modules/my_todo/tasks.post.hl
3. /modules/my_todo/tasks.put.hl
4. /modules/my_todo/tasks.delete.hl

Small note: the add-function calls returned no payload, but they were executed with system_instruction: true.