I did not start FRIDAY because I wanted another chatbot.
I started it because I wanted something closer to the computer assistant I imagined while watching Iron Man.
I wanted to say what I needed in natural language and have a system figure out what to do: research something, call a tool, plan a task, generate an answer, verify it, and eventually take action.
That ambition was much larger than the first prototype.
And that was exactly why the project became valuable.
The dream was simple. The architecture was not.
A normal chatbot follows a relatively direct loop:
User → Model → Response
FRIDAY needed something more like:
User → Planner → Specialist Agent → Tools → Result → QA → Final Response
Once I started thinking this way, a new set of engineering problems appeared.
What should the planner decide?
When should an agent call a tool?
How should tool failures be represented?
How do we prevent an agent from confidently returning nonsense?
How do we preserve context without making every prompt enormous?
How do we trace what happened inside the system?
Those questions taught me that an AI application is still an application.
The model is only one component.
I underestimated orchestration
At first, I was fascinated by model capabilities.
I spent a lot of time thinking about which model to use and how powerful the responses could become.
But eventually I realized that model selection was not the hardest problem.
The hard problem was orchestration.
Suppose the user asks:
“Find the latest information about a technology, compare it with another option, and tell me what I should use for my project.”
That is not one operation.
It involves research, source selection, comparison, reasoning, and communication.
A useful assistant needs to recognize that structure.
This pushed me toward planner, research, developer, and QA roles rather than treating the model as one giant function.
Tool calls changed how I think about AI
A model can generate text very well, but it cannot magically know the current weather, inspect my GitHub repository, query a database, or execute a local command unless the surrounding system gives it those capabilities.
Tools are the bridge between language and action.
That made me start thinking of FRIDAY as a runtime rather than a prompt.
A prompt tells the model how to think about a task.
A runtime determines what the model is actually allowed to do.
That distinction matters for reliability and safety.
Failure: models time out too
One of the less glamorous lessons was dealing with model providers and infrastructure.
Requests can time out. Models can be unavailable. Model names can change. Providers can return errors. Network conditions can affect latency.
A beautiful agent graph is useless if the model call fails and the application has no recovery strategy.
So I learned to design around failure instead of pretending it does not exist.
That means:
- explicit timeouts
- structured errors
- retries where appropriate
- fallbacks when justified
- observable execution traces
- clear user-facing failure messages
The goal is not to make AI systems never fail.
The goal is to make failure understandable and recoverable.
The biggest trap: making the agent too smart
It sounds strange, but one of the lessons I keep returning to is that an agent does not need unlimited freedom.
If every request can trigger every tool, the system becomes difficult to reason about.
A better design is often constrained capability.
Give the research agent research tools.
Give the developer agent code-related tools.
Give the QA agent verification responsibilities.
Make transitions explicit.
This is similar to good software architecture: small components with clear responsibilities are easier to debug than one giant component that “does everything.”
I also learned that memory is not magic
When building an assistant, it is tempting to say, “It should remember everything.”
But useful memory is selective.
Some information belongs to the current task.
Some information is a stable preference.
Some information is temporary.
Some information should never be retained.
That forced me to think about context as a resource that needs design, not as an infinite bucket.
What FRIDAY changed in me
Before FRIDAY, I mostly thought about AI as a model problem.
After working on it, I think about AI as a systems problem.
The interesting questions are now:
- How do we route tasks?
- How do we expose tools?
- How do we observe execution?
- How do we recover from failure?
- How do we evaluate output quality?
- How do we keep the system predictable?
Those are software engineering questions wearing an AI costume.
What I would build differently
If I restarted FRIDAY, I would begin with one reliable workflow rather than trying to create a general-purpose assistant immediately.
For example:
- Understand the request.
- Create a plan.
- Call one or two tools.
- Validate the result.
- Produce a final answer.
- Log every important step.
Then I would add capabilities one by one.
That approach would make evaluation much easier.
The lesson I keep
The future of AI applications is not just about bigger models.
It is about better systems around models.
A great model inside a badly designed application is still a bad product.
A capable model with good tools, clear boundaries, strong observability, useful memory, and reliable failure handling can become something much more powerful.
FRIDAY is still a work in progress.
That is okay.
Some projects are valuable because they ship.
Others are valuable because they change the questions you know how to ask.
FRIDAY did the second thing for me.
It made me stop asking, “How do I make the AI smarter?” and start asking, “How do I build a system that can use intelligence reliably?”