Built from Calicut: How Tensor1 Thinks About AI and Software

Tensor1 is taking shape on the shores of Calicut.

We are an independent engineering collective and applied AI lab formed by developers working across Calicut's technology ecosystem. We are not organised around a large office, layers of management, or a catalogue of ready-made products. Tensor1 begins with a smaller idea: capable developers should be able to investigate difficult technical questions, build the systems needed to test them, and share what they learn.

Calicut is more than a line in our address. It is the environment in which the collective is growing. The developers around Tensor1 bring different experiences from software engineering, product development, infrastructure, data, and artificial intelligence. Working as a collective lets those perspectives meet without forcing every problem through the structure of a conventional software company.

Why an engineering collective?

Software is often divided into separate stages. One group studies a problem, another designs a solution, another implements it, and someone else operates it. Information is lost at every boundary.

We prefer a shorter loop.

The people asking the technical questions should be close to the code. The people building a system should understand the assumptions behind it. When an experiment fails, the feedback should reach the original idea quickly.

This does not mean one developer must know everything. It means the collective can bring together the right combination of skills for a problem while keeping communication direct. A project may involve an interface, an API, a retrieval layer, an evaluation system, and deployment infrastructure. Those pieces should be considered as one system rather than unrelated deliverables.

Software engineering comes first

Artificial intelligence does not replace software engineering. In useful systems, it depends on it.

Tensor1's capabilities span full-stack web applications, mobile applications, APIs, automation, data pipelines, and infrastructure. This foundation matters because a model is rarely the complete product. It needs a reliable way to receive information, use tools, retrieve the right context, expose results, handle failures, and fit into the way people already work.

Sometimes the correct solution may involve a language model. Sometimes it may be a deterministic service, a carefully designed interface, or a straightforward automation. Often it is a combination.

We want the technical choice to follow the problem—not the other way around.

Where applied AI fits

Our interest in AI is centred on systems rather than isolated model demonstrations.

That includes retrieval-augmented generation, agents that interact with tools, model and system evaluations, data infrastructure, and human–AI workflows. Each area raises questions that cannot be answered by looking only at a model's output.

Where did the context come from? What happens when information is missing? Which actions should require approval? How does the system behave after a model or prompt changes? Can a result be traced, measured, and improved?

These are software engineering questions as much as AI questions. They are also where an applied lab becomes useful: ideas can be turned into experiments, examined under realistic conditions, and developed further only when the evidence supports them.

Research through engineering

At Tensor1, research does not have to mean separating theory from implementation. Building can be part of the research method.

Our working loop is simple:

1. Start with a specific technical question.
2. Study the assumptions and existing approaches around it.
3. Build the smallest useful experiment.
4. Evaluate its behaviour, limits, cost, and failure cases.
5. Share what the experiment teaches us.

Some questions may become prototypes. Some prototypes may become dependable software. Others may be discarded because the evidence is not strong enough. All three outcomes are useful when they produce clearer understanding.

Still taking shape

Tensor1 is early.

We do not want to manufacture a long history, present experiments as finished products, or speak as though every interesting AI idea is already solved. The purpose of the lab is to create the conditions for careful work: independent developers, short feedback loops, working code, and enough honesty to report where an approach breaks.

The writing on this journal will document that process. We will publish technical notes, experiments, practical explanations, and observations from building across AI and software engineering.

Open source will be part of that direction. When an experiment produces a useful tool, reference implementation, evaluation method, or reusable component, we want other developers to be able to inspect it, question it, and build on it. Not every investigation will result in a release, but sharing working code is one of the ways we intend to keep the lab's ideas connected to evidence.

Tensor1 is rooted in Calicut, but the questions we care about are not local in scope. Dependable software, useful AI, and clear technical thinking matter wherever systems are built.

This is where we are starting.