An agentic employee (sometimes called a "digital employee," "AI employee," or "employee agent") refers to an autonomous AI system designed to function like a human worker inside an organization.

It's not a human person — it's an advanced AI agent that:

• Receives goals or tasks
• Reasons, plans, and breaks them down into steps
• Uses tools, accesses systems/APIs, searches for information, sends emails, updates records, creates documents, etc.
• Takes actions independently (or semi-independently) with very little or no constant human supervision
• Adapts to changes, learns from outcomes, and completes complex multi-step workflows

Key characteristics of an agentic employee

• Proactive — doesn't just answer questions; it acts to achieve results
• Goal-oriented — you give it an objective ("prepare the monthly sales report", "onboard this new hire", "resolve this IT ticket") and it figures out how to do it
• Persistent — many are designed to have memory across days/weeks, behave like a long-term team member
• Role-specific — often trained or configured for particular jobs (e.g., junior accountant agent, customer support agent, legal research agent, HR coordinator agent)

Real-world examples (as seen in 2025–2026 products & discussions)

• Salesforce Agentforce employee agents — update CRM records, summarize meetings, create cases, handle internal workflows
• Agentic Employee platforms for law firms — digital workers trained on firm data that draft documents, review contracts, do legal research
• HR agents that manage onboarding, shift scheduling, benefits questions, or performance review admin
• Finance/ops agents that reconcile accounts, chase approvals, generate reports

In short: while a traditional chatbot or copilot helps you work, an agentic employee is built to do parts of the job itself — like hiring a very capable, 24/7 digital teammate that never sleeps and can be scaled infinitely.

The term became popular around 2025–2026 as companies moved from "AI assistants" to "AI workers" in the so-called agentic enterprise.

Un empleado agentico (también llamado a veces "empleado digital", "agente empleado de IA", "trabajador agentico" o "AI employee") es un sistema de inteligencia artificial autónomo diseñado para funcionar como un trabajador humano dentro de una organización.

No es una persona real, sino un agente de IA avanzado que:

• Recibe objetivos o tareas
• Razona, planifica y descompone las tareas en pasos
• Usa herramientas, accede a sistemas/APIs, busca información, envía correos, actualiza registros, crea documentos, etc.
• Toma acciones de forma independiente (o semi-independiente) con muy poca o ninguna supervisión humana constante
• Se adapta a cambios, aprende de los resultados y completa flujos de trabajo complejos de varios pasos

Características clave de un empleado agentico

• Proactivo — no solo responde preguntas; actúa para lograr resultados
• Orientado a metas — le das un objetivo ("preparar el informe mensual de ventas", "incorporar a este nuevo empleado", "resolver este ticket de soporte") y él descubre cómo hacerlo
• Persistente — muchos están diseñados para tener memoria a lo largo de días/semanas y comportarse como un miembro del equipo a largo plazo
• Específico por rol — suelen estar entrenados o configurados para trabajos concretos (ej.: agente contable junior, agente de atención al cliente, agente de investigación legal, agente coordinador de RRHH)

Ejemplos reales (vistos en productos y discusiones de 2025–2026)

• Agentes empleados de Salesforce Agentforce — actualizan registros en CRM, resumen reuniones, crean casos, manejan flujos internos
• Plataformas de empleados agenticos para firmas de abogados — trabajadores digitales entrenados con los datos de la firma que redactan documentos, revisan contratos, hacen investigación legal
• Agentes de RRHH que gestionan onboarding, programación de turnos, preguntas de beneficios o administración de evaluaciones de desempeño
• Agentes de finanzas/operaciones que concilian cuentas, persiguen aprobaciones, generan reportes

En resumen: mientras un chatbot tradicional o un copiloto te ayuda a trabajar, un empleado agentico está construido para hacer partes del trabajo él mismo — como contratar a un compañero digital muy capaz, disponible 24/7, que nunca duerme y que se puede escalar infinitamente.

El término se popularizó alrededor de 2025–2026 cuando las empresas pasaron de "asistentes de IA" a "trabajadores de IA" en lo que se llama la empresa agentica o agentic enterprise.

Dear Antonio, Yes, that makes sense – the transition period until the widespread adoption of agentic AI employees is indeed a phase in which one should act strategically to avoid unnecessarily burning resources.

Antonio, what do you suggest we application developers should do in the meantime, until agentic employees are truly widespread? It will certainly take another 1–2 years, and the tools will become so much simpler that right now one is basically just paying tuition fees. But what can be done in practice – for example, should one already migrate their programs to the web now, wait a year, and then have them fully automatically transpiled? Or are there other steps to prepare without taking on too much risk?

Best regards, Otto

Dear Otto,

I think the key is the database engine to use and the data stored into it. It has to be an engine that allows "semantic search".

The agent will finally talk to the database and will do what it is expected to be done. I have the intuition that the GUI will vanish away, it will be no longer needed.

In example, when we currently "talk" to Alexa or Siri, we need no GUI, no screen. You talk and listen (and/or read).

We will be talking to a super employee that will do exactly what is required :wink:

LLM + MCP (database) + other required MCPs (printer, barcodes reader, cameras, etc)

Dear Antonio,

I agree that semantic databases will be central in the long term.

But the current reality is different. We are not yet in the “agentic employee” era — we are in an interregnum between classical software systems and future agent-driven architectures.

So the practical question is not only architectural — it is economic: Should developers focus on data architecture, API-first design, modular business logic, or something else?

And more importantly: How should software companies position themselves in the next 1–3 years to remain commercially competitive?

Many customers already expect web-based, AI-enhanced, or at least cloud-connected systems. Desktop-only solutions are clearly losing momentum.

How do we avoid investing heavily in paradigms that may disappear — while at the same time not losing customers today?

Best regards, Otto

Antonio Linares wrote:

I have the intuition that the GUI will vanish away, it will be no longer needed.

Lo que yo me imagino es que será algo así como los coches autónomos, al menos los de ahora, que aún mantienen volante y sistema de conducción "por humano".

Quitar la GUI supone darle el control total al Agente y IMHO debe haber una forma lateral de acceder a datos: Un acceso /safe sin pasar por el Agente. Me pido primero en la cola del paro.

Dear Otto,

I would focus on building a "skill" thats knows all that your app does and how to do each task.

Maybe Antigravity could help us on this. Going to make some tests... :idea:

Practical example:

1. I have given samples\misc\fivedbu.prg to Gemini 3.1

2. I have asked this:

   I want you to build a skill that identifies all the possible actions fivedbu.prg can perform, so that I can talk to an AI and ask it to execute any of those actions

3. It provided a complete explanation but then I insisted with this:

   What would be the SKILL file to build following the format https://antigravity.google/docs/skills ?

4. It built the right skill file:
   ---
   name: fivedbu-manager
   description: Manages local relational databases (DBF, NTX, CDX) and remote databases (ODBC, ADO, MySQL, MariaDB, Access, SQLite) using native FiveDBU functions. Use this skill when you need to explore schemas, create or modify table structures, execute indexes, perform CRUD operations, or do physical cleanup (Pack/Zap).
   ---

Goal

Act as the bridge between the user and the FiveDBU platform to manage databases, allowing for CRUD operations, structural modifications, and advanced queries either autonomously or assisted.

How to use it

When the user requests to operate on a database, map their intention to one of the following FiveDBU capabilities and execute the corresponding commands:

1. File and Connection Management

• Local Files: Use the application's functions to open .dbf files (including CDX/NTX indexes).
• ODBC/ADO Connections: To interact with DBASE, FOXPRO, EXCEL, MSACCESS, MSSQL, MYSQL, SQLITE, ORACLE, and POSTGRE data sources.
• Direct Connections: Establish connections to MySQL or MariaDB servers and list available schemas.

2. Record Manipulation (CRUD)

• Add/Edit: Use the quick edit capability (FASTEDIT) or append blank records (DbAppend).
• Logical and Physical Deletion: Mark records for deletion, delete them in bulk by evaluating conditions (DeleteFor), or recover them (Recall).
• Global Replacement: Mass update values in specific fields using conditional iterations (For/While).

3. Maintenance and Structure

• Structure (Struct): Define, add, or alter the table definition (name, type, length, decimals).
• Indexes: Build index tags defining the natural order, filters (For), or mathematical and logical rules (Unique, Descend).
• Physical Maintenance: Use Pack to purge records marked for deletion, or Zap to completely empty a table.
• Import/Export: Generate a Harbour code transcription (TxtStruct) to replicate tables.

4. Queries and Environment

• Search and Inspection: Initiate incremental searches (Search) relying on index keys.
• Filters and Queries: Build and apply local macros (DbSetFilter) or use the Query Builder to inject SQL clauses into an ADO recordset.
• Workareas: Gather information from active areas (Workareas) including Alias, Record Count, Shared Status, and Paths.

5. Integrated Development Tools

• Console and Processes: Interpret direct FiveDBU commands or execute small dynamic code scripts.
• Hex Editor: Analyze and edit binaries, .exe, .dll, or .dbf files at the byte level.
• WebApp: Launch the embedded web server to operate the database remotely.

Decision Tree

• If the user wants to connect to network databases -> Prioritize ODBC/ADO connectors.
• If the user needs to free up disk space or clean a table -> Suggest Pack or Zap, but remind them to change the environment to "Exclusive" mode.
• If there are file corruption issues -> Use the Hex Editor.
• If data searching/grouping is needed -> Choose between Search (for simple keys) and Query Builder (for complex comparison logics).

Important Rules

• The agent must always consider and verify if the environment allows exclusivity (Exclusive) or if it is shared (Shared) depending on the invoked tool.
• Act as an expert in xBase/Harbour systems, using precise technical terminology (Alias, RecNo, RDD).

Suposedly this skill file should be understood by Antigravity or any other AI with skills support :idea:

I am going to take this idea a further step and build a talking agent with it :wink:

This way we can check if we can replace fivedbu with a fivedbu Agent.

It would be a good test if you try to get your SKILLs from your PRGs :wink:

Implementation Plan for agentic_fivedbu.prg

This plan describes the creation of agentic_fivedbu.prg, an autonomous, AI-driven database management tool based on the HIX AIOS architecture and FiveDBU features.

Goal Description

Create an agentic interface for FiveDBU that allows users to interact with their databases (DBF, ADO, MySQL, etc.) using natural language and voice. It will combine the frontend capabilities of [chat.prg](file:///c:/AIOS/chat.prg), the backend reasoning of [aios.prg](file:///c:/AIOS/aios.prg), and the database management features of [fivedbu.prg](file:///c:/AIOS/fivedbu.prg) according to the rules in [agentic_fivedbu_skill.md](file:///c:/AIOS/agentic_fivedbu_skill.md).

Proposed Changes

Core Application

[NEW] agentic_fivedbu.prg

This will be the main entry point and the core reasoning loop for the database agent.

• Initialize the UI/Web Server similar to [chat.prg](file:///c:/AIOS/chat.prg) but adapted for database tasks.
• Implement the reasoning loop similar to [aios.prg](file:///c:/AIOS/aios.prg) but with a custom cSystemPrompt focused on the fivedbu-manager persona.
• Provide a set of functions (tools) that the AI can call to manage databases:
• db_open / db_connect (Local DBF, ODBC, ADO, MySQL)
• db_query (Execute SQL or XBase commands)
• db_structure (Get table structure)
• db_crud (Append, Edit, Delete records)
• db_maintenance (Pack, Zap, Index)

Agent Skills

[NEW] .agent\skills\fivedbu\fivedbu_skill.prg

A new skill module containing the Harbour functions that wrap FiveDBU operations to be called by the AI.

• Aios_DbOpen( hArgs )
• Aios_DbQuery( hArgs )
• Aios_DbStruct( hArgs )
• Aios_DbDeleteFor( hArgs )
• Aios_DbPack( hArgs )

[MODIFY] aios.prg

Register the new fivedbu skills in BuildAiosFunctions() and ExecuteAiosSkill() so the agent reasoning loop can understand and execute database commands.

[MODIFY] chat_script.js (Optional)

If specific UI features are needed for database rendering (e.g., rendering a grid data structure in the chat), we might need to add specific HTML structure handling. We will try to map table results to Markdown tables first.

Verification Plan

Automated Tests

1. Compile the new agentic_fivedbu.prg.
2. Ensure the embedded web server starts correctly and UI is accessible.
3. Send a test query via the GeminiCallFC to check if fivedbu functions are correctly registered and triggered.

Manual Verification

1. Run agentic_fivedbu.exe.
2. Talk/Type to the agent: "Abre la base de datos de ejemplo local y dime qué tablas tiene."
3. Ask the agent to show the structure of a specific table.
4. Tell the agent to add a test record.
5. Ask the agent to delete that record and execute a Pack.
6. Verify all these steps through the agent's responses and by manually checking the database file.

Dear Antonio,

One thought that comes to mind:

This approach assumes that our existing applications are the right foundation to build an agent layer on top of. But what if some of our systems were designed in a much simpler era and are heavily UI-driven or tightly coupled internally? In that case, would extracting low-level skills still be the right starting point — or would it make more sense to rethink parts of the architecture first?

I’m asking because for some of us, the real question might not be “How do we agentify what we have?” but “Is what we have structurally ready for that step?” I see the technical value of extracting skills from existing PRGs. But from a business perspective, I wonder whether it might be more effective to start from concrete use cases and derive the required skills from there. Otherwise we risk building a complete inventory of capabilities without a clearly defined problem to solve.

I think maybe we are looking at this from two different but complementary realities.

Your approach seems focused on infrastructure experimentation — making applications agent-callable by extracting low-level skills.

For some of us, however, the immediate pressure comes from concrete market demands: Customers want remote/web access Customers want flexible reporting and dynamic queries Customers want better tools to acquire and analyze clients

So our current priority may not be replacing the GUI with a talking agent.

It may be: Architecture modernization Stronger reporting capabilities Optional AI enhancements on top of existing workflows

In that sense, AI could help us modernize and extend our systems — without necessarily replacing them.

I would be very interested in your view on how these two paths converge in the medium term.

Best regards, Otto

Dear Otto,

web is also the past already :wink:

Dear Antonio, Whatever comes after the web, we still have to operate in the present market. Best regards, Otto