AI & Technology
September 2026
7 min read
Small A&E firms carry business development, engineering, drafting, quality control, accounting, and the administration that holds all of it together — usually with very few people between them. At that scale, the project management system is not a reporting layer bolted onto the work. It is often the only place where the work is written down at all.
This is the case study of how we run that, and where an AI agent fits into it. We use Zoho Projects as the system of record. We use an AI agent — we call ours Ted — as an assistant that works against that record. The distinction between those two roles is the entire point of this article, and getting it backwards is the most common way small firms make this harder than it needs to be.
The Problem: Administrative Work Scales Worse Than Engineering
Engineering work scales predictably. If we take on a project, we know roughly how many hours of analysis, drafting, and review it will consume. Administrative work does not behave that way. Every new project adds a folder structure, a deliverable register, a set of submittal dates, a client contact record, and a chain of status updates that someone has to maintain. Add a project and you have added perhaps forty small acts of bookkeeping, none of which is engineering, all of which matter.
In a larger practice, that overhead is absorbed by a dedicated project controls group. In a small firm it is absorbed by the people doing the engineering — usually at the end of the day, usually incompletely. The usual result is that the project management tool becomes a place where information goes to be recorded accurately and discovered too late.
Why the System of Record Has to Come First
Before we automated anything, we made a deliberate decision about where the truth lives. It lives in Zoho Projects. Not in an email thread, not in one person's memory, not in a spreadsheet that one person maintains and nobody else opens.
That sounds obvious and it is frequently skipped. A great many small firms have a project management subscription and still answer the question "where is this project?" by asking a person. The subscription exists, but the system of record does not, because the data is entered inconsistently and trusted conditionally.
Two things fixed that. First, we structured the portal so that every project follows the same shape — the same task list stages, the same naming conventions, the same status vocabulary. Second, and more importantly, we stopped treating the record as something a human files into by hand.
What the Agent Actually Does
Here is the part that is easy to describe badly. Our AI agent is not a project manager. It does not decide what work to do, assign priority, or exercise judgment about engineering. It does four administrative things, repeatedly, without being asked:
It consolidates status. The agent reads the project record and produces a daily operational report — what moved, what is stalled, what is due, what has been waiting on someone. That report goes out every morning. Nobody has to open the project management tool to know the state of the firm.
It keeps the record aligned with reality. If a deliverable was issued, the agent reconciles that against the deliverable register. If a task's status does not match what actually happened, that discrepancy surfaces rather than sitting quietly in the portal.
It handles intake. New project information arrives from clients in whatever format the client prefers — an email, a PDF, a phone note transcribed into text. The agent extracts the structured fields and prepares the project record, so setup is a review step rather than a data-entry task.
It watches the calendar and the inbox. Deadlines, submittal dates, and client correspondence are monitored, and anything that needs a human decision is surfaced rather than acted on.
Notice what is absent from that list: no engineering decisions, no client commitments, no approvals. The agent prepares and surfaces. A licensed person decides.
Why Zoho Projects Specifically
The tool choice matters less than the discipline of having one, but Zoho Projects has suited us for three practical reasons.
The data is structured and retrievable. Because projects, tasks, and statuses live in defined fields rather than free text, a program can read them reliably. A system where status is a paragraph in a description field is not machine-readable no matter how well it is written. The API access is what makes the agent's work possible at all — it is not a nice-to-have, it is the precondition.
It is priced for a small firm. A per-user model at enterprise pricing is a real constraint for a small practice, not a rounding error, and it shapes the whole approach: a small firm needs a tool whose cost does not punish it for the size it actually is.
It does not try to be everything. We use Zoho Projects for project structure and status. We use separate tools for accounting, for document storage, and for engineering production. A tool that attempts to own all of that would be harder to automate against, not easier.
What Does Not Work Well Yet
An honest case study needs this section.
Adoption is the hard part, not automation. The agent can only work against a record that is maintained. If a task status is stale because someone did not update it, the agent will faithfully report something that is no longer true. Automation amplifies the quality of the underlying data — including its defects.
Per-user licensing constrains a small firm. When only a few people are doing the work and all of them need access, each additional seat is a meaningful line item rather than a marginal one. That is a real consideration for any small practice evaluating this class of tool, and it is worth pricing honestly before committing.
The agent cannot exercise judgment. This is a limitation by design, and it is worth stating plainly because it is also the safety property. An agent that could decide would be an agent that could be wrong in a way that matters professionally. Ours cannot, and we intend to keep it that way.
Licensure does not transfer to a tool. When a Professional Engineer seals and signs a set of plans, that seal is personal and professional. No amount of workflow automation changes who is accountable for the engineering. Our own policies state this plainly: the use of AI changes the drafting and administrative process, never the professional responsibility.
What We Would Tell Another Small Firm
If you are a practice of two to ten people considering this, three things we would say from experience.
Pick your system of record before you automate anything. Every hour spent automating against inconsistent data is an hour that makes the inconsistency faster and more convincing. Standardize the structure first. It is the least glamorous step and the one that determines whether the rest works.
Give the agent an administrative job, not a decision. The value is in the repetitive work that nobody in a small firm has time for — status consolidation, register reconciliation, intake structuring, monitoring. That is where the hours come back. Delegating judgment is not an efficiency gain; it is a liability.
Expect the tool to be the easy part. The software is a subscription. The discipline of maintaining a record is a practice, and it is the thing that actually determines whether a small firm can operate like a much larger one without taking on the overhead of becoming one.
We are still early in this. What we have is a small firm that knows the state of its work every morning without anyone assembling it, and engineers who spend their time on engineering rather than on the record of it. For a firm our size, that is the whole point.
Las firmas pequeñas de arquitectura e ingeniería llevan desarrollo de negocio, ingeniería, dibujo, control de calidad, contabilidad y la administración que sostiene todo lo demás, normalmente con muy pocas personas entre todas ellas. A esa escala, el sistema de gestión de proyectos no es una capa de reportes añadida al trabajo. Suele ser el único lugar donde el trabajo queda escrito.
Este es el caso de estudio de cómo lo manejamos, y dónde encaja un agente de IA. Usamos Zoho Projects como sistema de registro. Usamos un agente de IA — al nuestro lo llamamos Ted — como asistente que trabaja sobre ese registro. La distinción entre esos dos roles es el punto central de este artículo, e invertirla es la forma más común en que las firmas pequeñas se complican innecesariamente.
El Problema: el Trabajo Administrativo Escala Peor que la Ingeniería
El trabajo de ingeniería escala de forma predecible. Si tomamos un proyecto, sabemos aproximadamente cuántas horas de análisis, dibujo y revisión consumirá. El trabajo administrativo no se comporta así. Cada proyecto nuevo añade una estructura de carpetas, un registro de entregables, fechas de sometimiento, un registro de contacto del cliente y una cadena de actualizaciones de estado que alguien tiene que mantener. Agregue un proyecto y habrá agregado quizás cuarenta pequeños actos de contabilidad, ninguno de los cuales es ingeniería, y todos los cuales importan.
En una práctica más grande, esa carga se absorbe con un grupo dedicado de control de proyectos. En una firma pequeña la absorben las personas que hacen la ingeniería, normalmente al final del día, normalmente de forma incompleta. El resultado habitual es que la herramienta de gestión de proyectos se convierte en el lugar donde la información va a ser registrada con precisión y descubierta demasiado tarde.
Por Qué el Sistema de Registro Debe ir Primero
Antes de automatizar nada, tomamos una decisión deliberada sobre dónde vive la verdad. Vive en Zoho Projects. No en un hilo de correo, no en la memoria de una persona, no en una hoja de cálculo que una persona mantiene y nadie más abre.
Eso suena obvio y se omite con frecuencia. Muchísimas firmas pequeñas tienen una suscripción de gestión de proyectos y aun así responden la pregunta "¿en qué estado está este proyecto?" preguntándole a una persona. La suscripción existe, pero el sistema de registro no, porque los datos se ingresan de forma inconsistente y se confían de manera condicional.
Dos cosas resolvieron eso. Primero, estructuramos el portal para que cada proyecto siga la misma forma: las mismas etapas en la lista de tareas, las mismas convenciones de nombres, el mismo vocabulario de estados. Segundo, y más importante, dejamos de tratar el registro como algo que un humano archiva a mano.
Qué Hace Realmente el Agente
Esta es la parte que es fácil describir mal. Nuestro agente de IA no es un gerente de proyectos. No decide qué trabajo hacer, no asigna prioridades, no ejerce juicio sobre ingeniería. Hace cuatro cosas administrativas, repetidamente, sin que se lo pidan:
Consolida el estado. El agente lee el registro del proyecto y produce un reporte operativo diario: qué avanzó, qué está detenido, qué vence, qué está esperando por alguien. Ese reporte se emite cada mañana. Nadie tiene que abrir la herramienta de gestión para saber el estado de la firma.
Mantiene el registro alineado con la realidad. Si un entregable fue emitido, el agente lo concilia contra el registro de entregables. Si el estado de una tarea no coincide con lo que realmente ocurrió, esa discrepancia sale a la superficie en vez de quedarse quieta en el portal.
Gestiona la recepción de información. La información de un proyecto nuevo llega del cliente en el formato que el cliente prefiera — un correo, un PDF, una nota telefónica transcrita a texto. El agente extrae los campos estructurados y prepara el registro del proyecto, de modo que la configuración es un paso de revisión y no una tarea de digitación.
Vigila el calendario y la bandeja de entrada. Se monitorean los plazos, las fechas de sometimiento y la correspondencia con el cliente, y todo lo que requiere una decisión humana sale a la superficie en lugar de ejecutarse.
Note lo que está ausente de esa lista: ninguna decisión de ingeniería, ningún compromiso con el cliente, ninguna aprobación. El agente prepara y expone. Una persona con licencia decide.
Por Qué Zoho Projects en Particular
La elección de la herramienta importa menos que la disciplina de tener una, pero Zoho Projects nos ha servido por tres razones prácticas.
Los datos son estructurados y recuperables. Como los proyectos, las tareas y los estados viven en campos definidos en lugar de texto libre, un programa puede leerlos de forma confiable. Un sistema donde el estado es un párrafo en un campo de descripción no es legible por máquina, sin importar lo bien escrito que esté. El acceso por API es lo que hace posible el trabajo del agente: no es un extra deseable, es la precondición.
Tiene un precio para una firma pequeña. Un modelo por usuario con precio empresarial es una restricción real para una práctica pequeña, no un error de redondeo, y condiciona todo el enfoque: una firma pequeña necesita una herramienta cuyo costo no la castigue por el tamaño que realmente tiene.
No intenta ser todo. Usamos Zoho Projects para la estructura del proyecto y el estado. Usamos herramientas separadas para contabilidad, para almacenamiento de documentos y para producción de ingeniería. Una herramienta que intentara apropiarse de todo eso sería más difícil de automatizar, no más fácil.
Lo Que Todavía No Funciona Bien
Un caso de estudio honesto necesita esta sección.
La adopción es la parte difícil, no la automatización. El agente solo puede trabajar sobre un registro que se mantiene. Si el estado de una tarea está desactualizado porque alguien no lo actualizó, el agente reportará fielmente algo que ya no es cierto. La automatización amplifica la calidad de los datos subyacentes, incluidos sus defectos.
La licencia por usuario limita a una firma pequeña. Cuando solo unas pocas personas hacen el trabajo y todas necesitan acceso, cada puesto adicional es una partida significativa y no marginal. Es una consideración real para cualquier práctica pequeña que evalúe esta clase de herramienta, y vale la pena cotizarla con honestidad antes de comprometerse.
El agente no puede ejercer juicio. Es una limitación por diseño, y vale la pena decirla con claridad porque también es la propiedad de seguridad. Un agente que pudiera decidir sería un agente que podría equivocarse de una forma que importa profesionalmente. El nuestro no puede, y pretendemos que siga así.
La licencia profesional no se transfiere a una herramienta. Cuando un Ingeniero Profesional sella y firma un juego de planos, ese sello es personal y profesional. Ninguna cantidad de automatización de flujo de trabajo cambia quién es responsable de la ingeniería. Nuestras propias políticas lo dicen con claridad: el uso de IA cambia el proceso de dibujo y administrativo, nunca la responsabilidad profesional.
Qué le Diríamos a Otra Firma Pequeña
Si usted tiene una práctica de dos a diez personas y está considerando esto, tres cosas que diríamos desde la experiencia.
Elija su sistema de registro antes de automatizar cualquier cosa. Cada hora dedicada a automatizar sobre datos inconsistentes es una hora que vuelve la inconsistencia más rápida y más convincente. Estandarice primero la estructura. Es el paso menos vistoso y el que determina si el resto funciona.
Dele al agente una tarea administrativa, no una decisión. El valor está en el trabajo repetitivo para el que nadie en una firma pequeña tiene tiempo: consolidación de estado, conciliación de registros, estructuración de información entrante, monitoreo. Ahí es donde se recuperan las horas. Delegar el juicio no es una ganancia de eficiencia; es un pasivo.
Espere que la herramienta sea la parte fácil. El software es una suscripción. La disciplina de mantener un registro es una práctica, y es lo que realmente determina si una firma pequeña puede operar como una mucho mayor sin asumir la carga de convertirse en una.
Estamos todavía al comienzo de esto. Lo que tenemos es una firma pequeña que conoce el estado de su trabajo cada mañana sin que nadie lo arme, e ingenieros que dedican su tiempo a la ingeniería en lugar de al registro de ella. Para una firma de nuestro tamaño, eso es todo el punto.
