Rentora

AI property operations for modern landlords.

Comment

Every other property AI handles one conversation at a time. Rentora knows the history of every relationship in your portfolio and reasons across all of them simultaneously - because the graph is the product.

Track: Agentic AI Track

Inspiration

Over the last decade, property management has stayed way more manual than it should be. Landlords and property managers still deal with tenant texts, calls, emails, spreadsheets, and vendor coordination just to handle normal day-to-day issues. Most existing “AI property tools” still act like simple chatbots. They answer one message, maybe route one task, then move on without understanding the bigger picture. They do not really know the tenant, the unit history, the lease, the vendor track record, or whether the same problem has happened before. That was the main inspiration behind our project.

We wanted to build something that felt much closer to how real property operations actually work. Property management is not just a list of disconnected conversations. It is a network of relationships between properties, units, tenants, leases, maintenance history, payment status, and vendors. That made JAC a really strong fit, because the whole problem is naturally graph-shaped. The idea for our project came from combining that reality with agentic AI: instead of one isolated response, let AI walkers move through a connected property graph and reason across the full context before deciding what to do next.

What it does

Rentora is an agentic property operations system. A tenant can send a message like “the heater in my unit stopped working” or “the sink is leaking,” and the system handles much more than just turning that into a ticket. It classifies the issue, pulls relevant context, checks history, finds the best next step, and supports dispatch and follow-up.

Because the system is graph-based, it can reason across connected data. Instead of only seeing the text itself, it can look at whether this unit has had the same issue before, whether the tenant is on an active lease, which vendor handled similar jobs previously, and whether this should be flagged as a repeat problem instead of just another isolated repair. The result is a much smarter flow for maintenance and tenant operations than a normal chatbot or inbox automation system.

How we built it

We built the project around JAC and Jaseci. The main architecture is a graph model made up of properties, units, tenants, leases, tickets, and vendors. That graph is the foundation of the app. On top of it, we built walkers that handle different stages of the workflow. For example, there is a triage stage to classify the message, a context stage to pull lease and unit history, a vendor-related stage to identify the right contractor, a risk stage to flag repeat incidents or special cases, and an action stage to support notifications, dispatch, and follow-up.

We also connected Twilio for SMS communication so the tenant and landlord side of the workflow could feel real. On the frontend, we built a live dashboard experience where incidents, message flows, and AI processing could be visualized in a way that feels like a real product instead of a backend-only demo. A lot of the product thinking was around making the graph and walker logic visible and useful, not hidden behind a black box.

Challenges we ran into

One big challenge was making the live workflow actually feel live. It is one thing to have the logic working in isolation, but another thing to get SMS events, backend processing, persistence, and frontend updates all working together cleanly. Making sure live messages appeared properly in the dashboard and incidents flow took a lot of iteration.

Another challenge was product design. We did not want the app to feel like a generic admin panel or a fake dashboard filled with placeholder stats. We wanted it to feel like a real operations product. That meant rethinking the UI several times, deciding what data actually mattered, and making the AI workflow understandable without overwhelming the user. We also had to think carefully about separating live data from simulated demo data and making the system architecture stable as new features were added. Those product and engineering decisions were harder than they looked at first.

Accomplishments that we're proud of

The biggest thing we are proud of is the core idea itself: treating property operations as a graph problem instead of just a messaging problem. That is the part that really makes the project different. We were able to model the relationships between units, tenants, leases, vendors, and maintenance history in a way that matches how property management actually works.

We are also proud that we built this around JAC in a way that actually shows why the language is useful. The walker abstraction is not just there for show. It directly fits the way the system works, because each incoming event can move through a connected set of entities and decisions. On top of that, getting the SMS flow, dashboard, and agentic workflow concept tied together into one product direction was something we are really happy with.

What we learned

The biggest lesson was that agentic AI becomes much more powerful when it is grounded in structured relationships instead of isolated prompts. When the system has real connected context, it can do more than classify a message. It can reason about why something matters, what happened before, and what should happen next.

We also learned that JAC is a really natural fit for this kind of application. Property management is full of connected entities and event-driven decisions, so the graph and walker model made a lot of sense. Beyond that, we learned a lot about product design under hackathon pressure, especially around building interfaces for live workflows, handling real-time data, and making AI actions visible in a way that feels useful and trustworthy.

What's next for Rentora

The next step is turning Rentora into a more complete property operations platform. Right now, maintenance coordination is the clearest starting point, but the same graph-based approach can extend into lease renewals, payment issues, inspections, vendor performance tracking, and portfolio-wide analytics. The long-term opportunity is much bigger than just answering messages. It is about building an operating system for landlords and property managers.

On the product side, we want to keep improving the live dashboard, contact and property matching, and the AI workflow visibility so incoming messages are not just handled, but understood in full context. On the technical side, we want deeper graph reasoning, stronger persistence, cleaner real-time updates, and a more complete end-to-end flow from tenant issue to final resolution. The goal is to make Rentora feel less like a demo and more like the future of how smaller property teams actually run their portfolios.

Built With

Share this project:

Updates