DEV Community: Sumayea Rahman

From Apps to Agents: Is AI Changing the Interface of Computing?

Sumayea Rahman — Thu, 10 Sep 2026 12:17:07 +0000

For more than a decade, the smartphone has been the center of personal computing. We learned to unlock a screen, open an app, search, tap, type, and repeat.

Need directions?- Open a map.
Want to translate something?- Open a translation app.
Want to capture a moment?- Open the camera.
Need an answer?- Open a search engine or an AI app.

The smartphone gave us a powerful interface to the digital world.But what happens if the interface itself starts to disappear?

Recent developments in AI-powered wearables, particularly Meta's direction with AI glasses, made me think about a larger question:

"Are we moving from an application-centric world toward an agent-centric one?"

If that happens, the next major technology battle may not be about who makes the best smartphone.

It may be about who owns the interface between humans, AI, and the physical world.

The smartphone changed computing by putting it in our pockets

The smartphone wasn't simply a smaller computer. It changed how people interacted with technology.

The dominant model became:

Human
  ↓
Touchscreen
  ↓
Operating System
  ↓
App
  ↓
Information / Action

The app became the basic unit of interaction.

We learned to think in terms of applications:

Open Instagram.
Open Google Maps.
Open Gmail.
Open Spotify.
Open Uber.
Open ChatGPT.

This model created enormous businesses.

App stores became distribution platforms.
Operating systems became ecosystems.
And companies began competing not only on hardware, but on the software and services surrounding that hardware.

Apple is probably one of the strongest examples of this model.

Why does Apple win without winning every specification battle?

One thing I find particularly interesting about Apple is that technological leadership doesn't always mean having the most aggressive specification sheet.

Android manufacturers often experiment faster with hardware features, charging speeds, displays, cameras, customization, form factors, and other capabilities.

Yet the iPhone continues to command extraordinary loyalty and premium pricing.

Why?

Because the product isn't really just the phone.

It's the system around the phone.

Think about:

iPhone
  ↓
iOS
  ↓
App Store
  ↓
iCloud
  ↓
Apple Watch
  ↓
AirPods
  ↓
Mac
  ↓
Services

The value compounds across the ecosystem.

A user isn't necessarily evaluating a single device anymore.They are evaluating the cost and convenience of an entire digital environment.

This is where Apple's business strategy becomes particularly interesting. The annual iPhone cycle is not simply about making a dramatically different phone every year.

It continuously connects:

R&D → hardware → software → supply chain → marketing → upgrades → ecosystem → services

The product becomes part of a recurring economic cycle.

So perhaps Apple's most important achievement wasn't creating the best smartphone.

It was helping turn the smartphone into a platform.

But what happens when the interface changes?

This is where AI becomes interesting.

Imagine the traditional model:

User
 ↓
App
 ↓
UI
 ↓
API
 ↓
Backend
 ↓
Action

Now imagine:

User
 ↓
AI Agent
 ↓
Context
 ↓
Tools / APIs
 ↓
Action

The user doesn't necessarily need to know which application performs the task. They communicate the intention.

The agent figures out the process.

For example:

Instead of:
"Open Maps → search restaurant → check reviews → check availability → message a friend."

You might eventually say:

“Find me a good restaurant nearby for four people tonight and let my friend know where we're going.”

The interface has changed.The application may still exist underneath.But the user doesn't necessarily interact with it directly.
That distinction could be enormous.

Why Meta's AI glasses are strategically interesting

This is why I find Meta's AI glasses more interesting than simply another wearable product.

Glasses are already part of human behavior.
People already wear them.

Meta doesn't necessarily need to convince everyone to adopt an entirely new category of object.

Instead, it can add:

cameras
microphones
speakers
AI
connectivity
contextual awareness

to something people already understand.

That creates a different interaction model.

Instead of:

World
 ↓
Human
 ↓
Phone
 ↓
Screen
 ↓
App

we could move toward:

World
 ↓
Sensors
 ↓
AI
 ↓
Human
 ↓
Action

The computer becomes less visible.

That may be one of the most important trends in computing.

From GUI to contextual computing

The graphical user interface was revolutionary because it made computers easier to interact with.

The smartphone made that interface portable.
AI could make the interface contextual.

Consider this scenario.

You're walking through a city and see a sign written in a language you don't understand.

Traditional computing:

See sign
 ↓
Take phone out
 ↓
Open camera
 ↓
Open translation
 ↓
Scan
 ↓
Read result

Contextual computing:

See sign
 ↓
AI understands what you're seeing
 ↓
Translation is provided

The difference isn't simply convenience.

It's a different relationship between human and computer.

The computer is increasingly moving from something we operate toward something that understands context.

This creates a new software engineering question

If agents become the primary interface, what happens to applications?

Today, developers spend enormous effort designing user interfaces.

Buttons.
Menus.
Forms.
Navigation.
Dashboards.
Screens.

But an agent doesn't necessarily need the same interface.

It needs:

APIs
tools
permissions
structured data
reliable actions
context
authentication
observability
safety mechanisms

This could shift part of software development from:

“How should the user interact with this screen?”

toward:

“How can an intelligent system safely interact with this capability?”

That is a very different engineering problem.

The new platform battle may be about the context layer

This is where I think things get particularly interesting.

In the traditional ecosystem, platforms compete for control over:

hardware + operating system + applications + distribution.

In an AI-first ecosystem, another layer becomes extremely valuable:

context.

Who knows:

what I'm looking at?
where I am?
what I'm doing?
who I'm communicating with?
what I prefer?
what I did yesterday?
what I'm trying to accomplish?
which actions I'm authorized to take?

That information can make an AI dramatically more useful.

And whoever controls that context layer could have enormous platform power.

This creates an interesting question for Apple

Apple's ecosystem is one of its greatest strengths. But every strength can become a constraint when the technological paradigm changes.

Apple has spent years building a tightly integrated environment around its devices and operating systems. That is extremely powerful when the primary interface is:

device → OS → app → user

But if computing shifts toward:

context → AI → agent → action

the rules could change.

Apple's ecosystem could become a massive advantage if it successfully integrates AI across its devices.

But it could also become a constraint if another company establishes the dominant AI interaction layer outside Apple's ecosystem.

That is the strategic tension I find fascinating.

And Meta has a different starting position

Meta doesn't need to replace the smartphone immediately.

It can potentially make the smartphone less central over time.

The glasses can coexist with the phone.

The phone can provide connectivity, computation, storage, and other infrastructure.

Meanwhile, the glasses gradually become the primary interface for certain interactions.

This is strategically interesting because disruption doesn't always mean:

“Replace the old technology tomorrow.”

Sometimes it means:

“Make the old technology increasingly unnecessary.”

What happens to the App Store?

This is one of the questions I think software developers should pay attention to.

The smartphone created the app economy.

But imagine a future where users interact primarily through agents.

Would we still download dozens of applications?

Maybe.

But perhaps the user experience becomes:

Intent
 ↓
AI Agent
 ↓
Discover capability
 ↓
Authenticate
 ↓
Execute

The application still exists. But it becomes infrastructure behind the agent.

In that world, APIs and agent-accessible capabilities could become as strategically important as graphical interfaces are today.

That doesn't mean traditional applications disappear. It means the center of gravity could move.

This changes what I think software engineers should learn.

If this transition continues, knowing how to build a polished frontend will remain valuable. But it won't be enough.

Engineers may increasingly need to understand:

Frontend
→ interfaces and user experience

Backend
→ APIs, databases, authentication

AI
→ models, inference, prompting, context

Agents
→ tool use, planning, workflows

Systems
→ latency, scalability, reliability

Security
→ permissions, identity, privacy

Product thinking
→ what should the system actually do?

The most valuable engineers may increasingly be those who can move between these layers.

My hypothesis

I don't think the smartphone is disappearing tomorrow.

The smartphone is too deeply embedded in modern infrastructure.

Instead, I think we are entering a period where the smartphone becomes one component of a much larger computing environment.

The evolution may look something like:

Desktop
   ↓
Laptop
   ↓
Smartphone
   ↓
Wearables
   ↓
Ambient AI
   ↓
Agentic computing

Each transition doesn't completely destroy the previous one. It changes what the previous technology is for.

The desktop didn't disappear because of laptops.
The laptop didn't disappear because of smartphones.
And smartphones may not disappear because of AI wearables.

Their role may simply change.

The real competition may not be Apple vs Meta

This is perhaps the biggest conclusion I reached while thinking about this.

The next major competition may not be:

iPhone vs Android

or even:

Apple vs Meta.

It could be:

Who becomes the trusted interface between humans and intelligent machines?

Apple has:
hardware + ecosystem + privacy + premium positioning

Meta has:
social platforms + AI + wearables + enormous behavioral data

Google has:
search + Android + AI + maps + data + cloud

OpenAI and other AI companies have:
models + agents + developer ecosystems

The battle is therefore moving beyond devices.
It is becoming a battle over interaction, intelligence, context, and trust.

What does this mean for developers?

For me, this is the most exciting part.

I'm currently transitioning from a finance background into software engineering.

That journey has changed how I look at technology. I used to look primarily at the business side:

How does a company make money?

Now I'm increasingly interested in another question:

What technical architecture makes that business model possible?

And that leads to an even better question:

When technology changes, which part of the system captures the value?

That's the question I want to keep exploring as I learn and build.

Not simply:

“What is the newest technology?”

But:

“What changes when this technology becomes normal?”

Final thought

The smartphone era taught us to reach for computers.

The next era may teach computers to reach toward us.

Not literally. But contextually.

They may understand what we see, hear, need, and intend—and increasingly help us act without requiring us to navigate a traditional interface.

If that happens, the biggest opportunity for software engineers may not be building another application.

It may be building the intelligent systems underneath the interface.
And the companies that understand that shift early could define the next generation of computing.

The next platform war may not be about who makes the best device.

It may be about who owns the context layer between humans, AI, and the physical world.

Disclosure: This article was developed with AI assistance for brainstorming, structure, and language refinement. The ideas, questions, and final editorial direction were reviewed and shaped by the author.

Building My First AI Agent API with FastAPI and Mistral AI

Sumayea Rahman — Mon, 08 Jun 2026 16:55:04 +0000

Coming from a non-technical background, learning Python and AI has been one of the most challenging things I've done.

Over the last few days, I built and deployed my first AI Agent API: Agentic Finance Beast.

What it does:

Answers general questions using Mistral AI
Uses a calculator tool when mathematical reasoning is required
Implements a simple agent workflow for tool selection
Exposes everything through a FastAPI backend
Runs as a publicly accessible cloud API
Tech Stack
Python
FastAPI
Mistral AI
Render
Custom LangGraph-style Agent Architecture
What I Learned

Building an AI application is very different from watching tutorials.

I learned how to:

Design agent workflows
Integrate external LLM APIs
Build tool-calling logic
Handle environment variables securely
Deploy a production-ready API
Live Demo

https://agentic-finance-beast.onrender.com

GitHub Repository

https://github.com/Sumayea104/agentic-finance-beast

This is Day 4 of my journey toward becoming an AI Engineer.

Next stop: RAG systems, LangGraph, and multi-agent financial research systems.

Why I Built RAG From Scratch Before Using LangChain

Sumayea Rahman — Sun, 07 Jun 2026 08:21:00 +0000

Technical Note #01: Why I Built RAG From Scratch Before Using LangChain

Part of the Agentic Finance Beast Technical Notes series

Published: June 7, 2026
Reading Time: ~6 minutes

About This Note

This technical note documents my first implementation of a Retrieval-Augmented Generation (RAG) pipeline.

The goal was not to build a production-ready system.

The goal was to understand what actually happens between a user's question and an AI-generated answer before relying on frameworks such as LangChain.

Rather than starting with abstractions, I wanted to build the core pieces myself and learn where real-world AI systems succeed and fail.

TL;DR

I built a minimal RAG pipeline from scratch using Gemini Embeddings, cosine similarity search, and Mistral.

The biggest lesson wasn't prompt engineering.

It was discovering that retrieval quality often has a greater impact on answer quality than the language model itself.

The Question That Started It

Most RAG tutorials follow a similar pattern:

Install LangChain.
Connect a vector database.
Load a document.
Ask questions.

Within minutes, you have a working application.

That's impressive.

But it left me with a question:

If the system retrieves the wrong information, how would I debug it?

Frameworks make development faster, but they also hide implementation details.

Before using those abstractions, I wanted to understand the individual components behind Retrieval-Augmented Generation.

So I built a simple version myself.

No LangChain.

No vector database.

No orchestration framework.

Just Python, embeddings, similarity search, and an LLM.

What Is RAG?

Retrieval-Augmented Generation combines two systems:

A retrieval system that finds relevant information.
A generation system that uses that information to answer questions.

Instead of relying entirely on the language model's training data, relevant information is retrieved at runtime and injected into the prompt.

The simplified workflow looks like this:

Document
   ↓
Chunking
   ↓
Embeddings
   ↓
Similarity Search
   ↓
Context Retrieval
   ↓
LLM Response

This architecture allows AI systems to answer questions using external knowledge without retraining the model.

The Architecture I Built

My implementation consisted of five core stages:

Document
   ↓
Sentence-Based Chunking
   ↓
Gemini Embeddings
   ↓
Cosine Similarity Search
   ↓
Mistral Answer Generation

The knowledge base contained a short document about AI agents.

Users could ask questions, and the system would retrieve relevant information before generating a response.

Step 1: Chunking the Document

The first step was splitting the document into smaller pieces.

I used a simple sentence-based approach:

chunks = [
    s.strip() + "."
    for s in document.replace("\n", " ").split(". ")
    if s.strip()
]

At first, this felt like a minor preprocessing step.

It wasn't.

I quickly realized that chunking affects retrieval quality directly.

Large chunks preserve context but often include irrelevant information.

Small chunks improve retrieval precision but can lose important context.

Even in this small project, chunking turned out to be a meaningful engineering decision.

Step 2: Generating Embeddings

After chunking the document, I generated embeddings using Gemini's embedding API.

Each chunk was converted into a high-dimensional vector representation.

embedding = data.get("embedding", {}).get("values", [])

Before building this project, embeddings felt somewhat magical.

After seeing the actual vectors returned by the API, the concept became easier to understand.

Embeddings allow machines to compare meaning instead of matching exact words.

For example, a query about decision-making could retrieve information related to reasoning even if the exact keywords do not appear.

That capability is what makes semantic search possible.

Step 3: Implementing Similarity Search

Instead of using a vector database, I implemented cosine similarity manually.

def cosine_similarity(a, b):
    dot = sum(x * y for x, y in zip(a, b))
    norm_a = math.sqrt(sum(x * x for x in a))
    norm_b = math.sqrt(sum(x * x for x in b))
    return dot / (norm_a * norm_b)

This was one of the most interesting parts of the project.

Before building it, vector search seemed complicated.

After implementing it myself, I realized the mathematics behind retrieval is relatively straightforward.

The challenge is not the formula.

The challenge is consistently retrieving the most useful context.

Step 4: Finding Relevant Information

When a user asks a question, the same embedding model converts the question into a vector.

The query embedding is then compared against every document embedding.

best_idx = similarities.index(max(similarities))

The chunk with the highest similarity score becomes the retrieved context.

For example, questions such as:

What is an AI agent?
How do AI agents differ from traditional programs?
What can financial AI agents do?

successfully retrieved relevant information from the knowledge base.

For a minimal implementation, the results were surprisingly effective.

Step 5: Grounding the Response

Once relevant context is retrieved, it is passed to Mistral alongside the user's question.

Context: {context}

Question: {question}

The model is instructed to answer using only the provided context.

This is where retrieval and generation come together.

Without retrieval, the model answers based on its training data.

With retrieval, the model answers using information supplied at runtime.

This simple shift dramatically improves factual grounding.

What Surprised Me Most

Before building this project, I assumed the language model would be the most important part of the system.

I was wrong.

Most answer quality issues were retrieval issues.

When retrieval returned weak context, answer quality suffered.

When retrieval returned relevant context, answer quality improved significantly.

This changed how I think about AI applications.

Prompt engineering matters.

Model selection matters.

But retrieval quality often determines whether an answer is useful in the first place.

Engineering Tradeoffs I Encountered

Even in a small project, several tradeoffs became visible.

Simplicity vs Context

Sentence-level chunking was easy to implement.

However, preserving context becomes more difficult as chunk sizes become smaller.

Precision vs Coverage

Retrieving a single best match is simple.

Retrieving multiple relevant chunks provides broader coverage but introduces additional complexity.

Learning vs Production

Building retrieval manually helped me understand the system.

In production environments, dedicated vector databases and retrieval frameworks become necessary.

What I Got Wrong

Before starting this project, I believed prompt engineering would have the greatest impact on answer quality.

The implementation showed otherwise.

Poor retrieval produced poor answers regardless of prompt quality.

Improving retrieval had a larger effect than rewriting prompts.

That was one of the most valuable lessons from the entire exercise.

Limitations of This Version

This implementation intentionally prioritizes learning over scalability.

Several important features are missing:

Top-K retrieval
Persistent vector storage
Metadata filtering
Conversation memory
Retrieval evaluation metrics
Hybrid search techniques

These limitations are acceptable because the objective was understanding the fundamentals rather than building a production-ready system.

What's Next

This implementation serves as the foundation for future work within Agentic Finance Beast.

The next improvements I plan to explore include:

Top-K retrieval instead of single-result retrieval
Better chunking strategies
Vector storage using pgvector
Financial document retrieval
Multi-step workflows with LangGraph
Agent memory and reasoning systems

Each improvement builds upon the concepts explored in this first implementation.

Final Thoughts

Building a RAG pipeline from scratch did not make me an expert in retrieval systems.

What it did provide was a practical understanding of how retrieval, embeddings, similarity search, and generation work together.

Frameworks such as LangChain are incredibly useful.

But understanding the fundamentals behind those abstractions provides a different kind of value.

When something breaks, I now have a mental model for where to investigate.

For me, that understanding made building from scratch worthwhile.

Repository

GitHub: https://github.com/Sumayea104/agentic-finance-beast